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(1) Real Party In Interest 

The real partly in interest in the above-referenced patent application is the 
Applicant Bradley S. Templeton of Sunnyvale, California. 

(2) Related Appeals and Interferences 

5 To the knowledge of the Applicants there are no related appeals or 

interference proceedings which will directly affect, or be directly affected by, or 
have a bearing on, the Board's decision in this Appeal. The Applicant notes that 
corresponding patent applications in Canada (Appl. No. 2,352,165), the United 
Kingdom and in Germany (EP 1 127 444 B1) have been found to include 
10 allowable material or have issued as patents. 

(3) Status of Claims 

Claims 1 , 3-8, 54-57 and 72-98 are now pending. The Amendment filed 
May 9 th , 2008 included Claims 1 , 3-8, 54-57 and 72-96 which were original or 
previously presented and Claims 97 and 98 which were new. This Amendment 
15 was entered by the Examiner. Claims 28, 32, 42-49, 53 and 58-71 were 
previously cancelled. 

Claims 1, 3-8, 54-57 and 72-98 stand rejected as follows: 
Claims 92 and 96 were rejected under 35 U.S.C. 1 12, second paragraph. 
These rejections appear to have been resolved through an Examiner interview. 
20 Claims 88-89 and 91 were rejected under 35 U.S.C. 102(e) as being 

anticipated by Gisby at al. (US 6,044,146). 
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Claims 1, 3-8, 54-55, 72-79, 81-82, 84-85 and 87 were rejected under 35 
U.S.C. 103(a) as being unpatentable over Gisby et al. (US 6,044,146) in view of 
Yacenda et al. (U.S. 5,515,426). 

Claims 56-57 and 80 were rejected under 35 U.S.C. 103(a) as being 
5 unpatentable over Gisby et al. (US 6,044,146) in view of Yacenda et al. (U.S. 
5,515,426) and in further view of Vaios (U.S. 6,272,216). 

Claims 83, 86 and 90 were rejected under 35 U.S.C. 103(a) as being 
unpatentable over Gisby et al. (US 6,044,146) in view of Vaios (U.S. 6,272,216). 
Claims 92-96 are rejected under 35 U.S.C. 103(a) as being unpatentable 
10 over Gisby et al. (US 6,044,146) in view of Yacenda et al. (U.S. 5,515,426) and 
in further view of Vardi et al. (U.S. 6,389, 1 27). 
(4) Status of Amendments 

An Amendment After Final was filed on May 9 th , 2008. This amendment 
was entered by the Examiner on June 2, 2008. 
15 (5) Grouping of Claims 

Claims 7, 8, 54, 55, 72-77, 79, 81, 82, 86, 95 and 96 stand with Claim 1. 
Claims 57 and 80 stand with Claim 56. Claim 90 stands with Claim 88. Claim 5 
stands with Claim 3. Claim 6 stands with Claim 4. Claims 85 and 87 stand with 
Claim 84. All other claims stand alone. The board is respectfully requested to 
20 consider each of Claims 1, 3, 4, 56, 78. 83, 84, 88, 89, 91-94. 97 and 98 
individually. 
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(6) Summary of the Claimed Subject Matter 

The invention relates to systems and methods of managing telephone 
calls and meetings, (% [0003]). 1 More specifically, typical embodiments of the 
invention include systems and methods of determining when participants, 
referred to as a requestor and target(s) (f [0008]), are mutually available at 
which time a call can be connected. A wide variety of factors may be used to 
determine availability of a participants flf [0009]), including for example, if a 
participant is already on the phone, if a participants has a scheduled availability 
(If [0012] and [0255]), if the participant has pressed a button, or the like. 

If a participant is unavailable, then a request for a call is queued flj 
[0012]). The system of the invention optionally monitors the availability of 
multiple targets and requestors, who may be queued to participate in a plurality 
of different calls (% [0136]). The requestor in one call request may be a target in 
another call request. When both participants are mutually available the call is 
automatically (Abstract) made or one of the participants is notified so that they 
can manually place the call. Calls are made in an order determined first by the 
order in which participants become available and second by an order in which 
requests were queued flj [0012]). For example, when a user becomes available 
and is a participant in more than one queued calls, the call placed in the queue 
first will typically be initiated first. 



' Page and line numbers refer to the application as published [US 2003/0191676 A I ]. References made 
herein to the specification as filed are meant to be illustrative examples and not an indication that the 
references are the only places within the specification that elements, limitations or features are taught. 



In some embodiments a user can assign priority to other participants 
before a call request is made (f [0011] and [0081]). This priority may be used to 
override the order of queued calls such that a call with a higher priority target is 
initiated before a call that was placed first in the queue (f [0012]). 
5 Some embodiments of the invention are directed toward preventing "call- 

tag" in which participants repeatedly try to reach each other at times when they 
are not available (f [0005]). 

In summary, independent Claim 1 recites a computer-implemented method 
for the intermediation of real time meetings. These meetings are mediated by a 
10 decider system (D) (FIG. 1A, % [0033]) and include at least a first meeting (M-A) and 
a second meeting (M-B). Claim 1 recites four potential participants in these two 
meetings: a target (T-A) and a requester (R-A) for the first meeting, and a target (T- 
B) and a requester (R-B) for the second meeting. However, one of these potential 
participants is actually a "common party" to the meetings, thus, there are three 
15 actual participants recited fl[ [0050] last sentence). 

More specifically, the decider system (D) (FIG. 3 Step 302, % [0050]) receives 
a request for the first meeting (M-A) including the requester (R-A) and target (T-A). 
This request is queued (FIG. 3 Step 304, If [0051]) and the decider system (D) then 
receives an availability status of each of the target (T-A) and requester (R-A) (FIG. 
20 6). These availability status can include a status of "not available," (f [0134]). 

The decider system (D) then receives a request for the second meeting (M-B) 
including the requester (R-B) and target (T-B) (% [0050]). The second meeting (M-B) 
is to be "disjoint" in time with the first meeting (M-A). One of the parties to the first 



Brief on Appeal 



5 



meeting (M-A) is the same as one of the parties to the second meeting (M-B) and is 
referred to as the "common party," (% [0050]). There are thus at least three distinct 
parties and two meetings. 

The second meeting (M-B) is queued by the decider system (D) (FIG. 3 Step 
5 304, H [0051]). The queue thus includes at least two meeting requests, having a 
common party. The decider system (D) then receives an availability status of each 
of the target (T-B) and requester (R-B). These availability status can include a 
status of "not available." 

Finally, when the common party and one of the other parties are mutually 
10 available (FIG. 3 step 306, f [0052]), the decider system (D) initiates (FIG. 8 steps 
802-806, U [0132]) one of the two meetings (M-A) and (M-B) (FIG. 3 step 308, % 
[0052]), and dequeues the request for that meeting, (FIG. 3 step 310, f [0052]). 

In summary dependent Claims 3 and 5 both include limitations reciting that 
availability is determined through a process call "polling," (f [0087]). 
15 In summary dependent Claims 4 and 6 both included limitations reciting that 

availability status is "pushed," (% [0087]). 

In summary dependent claim 56 includes limitations further comprising 
displaying an availability status of the target T-A on the requester system, along with 
an indication that the requestor has requested a meeting with the target, flf [0132], 
20 [0134], FIG. 6 "display"). 

In summary dependent claim 78 includes limitations that a non-common 
requester is part to another distinct meeting request, (% [0050]). 
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In summary dependent claim 84 includes limitations that the target is a 
specific individual selected by the requester, (f [0011]). 

In summary dependent claim 83 includes limitations specifying that the 
common party is one of the requestors and participates in both of the meetings, (% 
5 [0050]). 

In summary, independent Claim 88 recites a method comprising transmitting 
or receiving a first request for a first real-time meeting between a requestor and a 
first target, the requestor and the first target being individuals, (FIG. 3 step 302, % 
[0050]). A computing system is then used to determine that the first target is 

10 unavailable. The method includes waiting until the first target changes from being 
unavailable to being available, fll [0052], [0137] and [0267]). When the first target 
becomes available, it is determined if the requester is available, flj [0119] and 
[0137]). If the requestor is available, then the first real-time meeting is initiated, 
otherwise if the requester is unavailable, then the method waits until a time the 

15 requestor becomes available, flf [0137] and [0267], FIG. 5 step 502, [0054]). 

In summary, dependent Claim 89 recites determining if the first target is still 
available after the requester has become available; and if the target is available 
initiating the meeting, if the target is not available waiting until the target becomes 
available, (FIG. 3 step 306, f [0052]). 

20 In summary, independent Claim 97 is identical to independent Claim 88 

except that Claim 97 lacks the limitations "if the requestor is available, then initiating 
the first real-time meeting." 
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(7) Grounds of rejection to be reviewed on Appeal 

I, Whether Claims 88-89 and 91 were properly rejected under 35 U.S.C. 
5 102(e) as being anticipated by Gisbv at al. (US 6,044,146). 

(a) whether conditional language, such as if X then Y is equivalent to 
optional language such as "may." 

(b) whether conditional language, such as if X then Y, can be disregarded 
in rejecting a claim under 35 U.S.C. 102(e). 

10 (c) whether the Examiner has properly interpreted the claim terms 

"requestor becomes available" and "becomes available." 
(d) whether the cited art teaches having an available target, waiting for a 
requester to become available, when the requester becomes available 
finding that the target is no longer available and having to wait for the 

15 target to become available. 

II. Whether Claims 1, 3-8, 54-55. 72-79, 81-82, 84-85 and 87 were properly 
rejected under 35 U.S.C. 103(a) as being unpatentable over Gisbv et al. (US 
6,044,146) in view of Yacenda etal. (U.S. 5,515.426). 

(a) whether the Examiner has properly interpreted the claim terms 
20 "availability status." 

(b) whether the Examiner has properly interpreted the claim term 
"availability status," where "availability status" includes "not available." 
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(c) whether the Examiner has properly interpreted the claim term '"not 
available" in the claim element "receiving by the decider system (D) an 
availability status of R-A, where a possible availability status includes 
not available." 

5 (d) whether an "availability status" specified as being "one of in, out, and 

unknown" is taught by a teaching of "priority." 

(e) whether there is not proper motivation to combine the art as required to 
establish a prima facie case for rejection under 35 U.S. C. 103(a), 
because the combination of prior art suggested by the Examiner would 

10 produce a non-workable system. 

(f) whether the Examiner has properly interpreted the claim term "polled" 
as recited in Claims 3 and 5. 

(g) whether the cited art teaches pushing of status information to the 
decider system by the Target T-A (claim 4) or by the party (claim 6). 

15 (h) whether or not the limitations of Claim 78 require that a caller is a party 

to more than one request, 
(i) At issue in the rejection of Claim 84 is the feasibility of combining the 
cited art with official notice taken by the Examiner. 
III. Claims 56-57 and 80 were rejected under 35 U.S.C, 103(a) as being 
20 unpatentable over Gisbv in view of Yacenda and in further view of Vaios 
(U.S. 6,272,216. 

(a) At issue in the rejection of Claim 56 is whether the addition of the 
teachings of Vaios to those of Gisby would produce a result that is 
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contrary to the teachings of Gisby. and there would, therefore, not be a 
proper motivation to make the combination. 

IV. Claim 83, 86 and 90 were rejected under 35 U.S.C. 103(a) as being 
unpatentable over Gisby in view of Vaios. 

(a) At issue in the rejection of Claim 83 is whether the cited art teaches all 
of the limitations of Claim 83. 

V. Claims 92-92 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Gisby et al. in view of Yacenda and in further view of Vardi. 

(a) At issue in the rejection of Claim 92 is whether the Examiner has failed 
to present a prima facie case for rejection under 103(a) because the 
prior art does not teach or suggest all the claim limitations. 

(b) At issue in the rejection of Claim 93 is whether the cited art teaches all 
of the limitations of Claim 93, specifically, whether Vardi et al. teaches 
"wherein the requestor R-A changes states from not available to 
available, while waiting for the realtime meeting M-A," as recited in 
Claim 93. 

(c) At issue in the rejection of Claim 94 is whether the art cited by the 
Examiner includes all the limitations of Claim 94, specifically "wherein 
the requestor R-A participates in another distinct realtime meeting." 
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(8) Arguments 

I. Whether Claims 88-89 and 91 were properly rejected under 35 U.S.C. 
102(e) as being anticipated by Gisbv at al. (US 6,044,146). 
5 (a) whether conditional language, such as if X then Y is equivalent to 

optional language such as "may." 

This issue applies to Claims 88- 91 and 97-98. 

The Examiner has taken the position that conditional language within the 
claims is equivalent to optional language and can, therefore, be disregarded. 
10 The Applicant has taken the position that claim limitations of the form "if X then 
Y" are not equivalent to optional language and must be anticipated by the prior 
art in order for the claim be properly rejected under 102(e). 

Claim 88 recites a number steps concluding with: 

if the requestor is available, then initiating the first real-time meeting; and 
1 5 if the requester is unavailable, then waiting until a time the requestor 

becomes available. 

In the Final Office Action, the Examiner states: 

The limitation "if the requester is unavailable, then waiting until a time the 
20 requestor becomes available" does not occur in methods where the 

requester is available, in the previous limitations. Therefore, since Gisby 
et al. teaches that the requester is available, the limitation "if the requester 
is unavailable, then waiting until a time the requestor becomes available" 
is not required. 

25 

In response to this argument the Application requested that the Examiner 
provide statutory support for disregarding the limitations "if the requester is 
unavailable, then waiting until a time the requestor becomes available." 
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In the Advisory Action of June 2, 2008 the Examiner cited MPEP Sec. 



21 1 1 .04 which states "[c]laim scope is not limited by claim language that 

suggests or makes optional but does not require steps to be performed..." The 

Examiner further states "the if language utilized in the claim suggest but does not 

5 require certain steps to be performed when the claim scope is analyzed." 

MPEM Sec. 2111.04 states: 

Claim scope is not limited by claim language that suggests or makes 
optional but does not require steps to be performed, or by claim language 
that does not limit a claim to a particular structure. However, examples of 
10 claim language, although not exhaustive, that may raise a question as to 

the limiting effect of the language in a claim are: 

(A) "adapted to" or "adapted for" clauses; 

(B) "wherein" clauses; and 
15 (C) "whereby" clauses. 

The determination of whether each of these clauses is a limitation in a 
claim depends on the specific facts of the case. In Hotter v. Microsoft 
Corp., 405 F.3d 1326, 1329, 74 USPQ2d 1481, 1483 (Fed. Cir. 2005), the 

20 court held that when a "'whereby' clause states a condition that is material 

to patentability, it cannot be ignored in order to change the substance of 
the invention." Id. However, the court noted (quoting Minton v. Nat'l Ass'n 
of Securities Dealers, Inc., 336 F.3d 1373, 1381, 67 USPQ2d 1614, 1620 
(Fed. Cir. 2003)) that a '"whereby clause in a method claim is not given 

25 weight when it simply expresses the intended result of a process step 

positively recited.'" Id< 



The Applicant argues that that the "if X then Y" structure of the claim 
limitations of Claim 88 is not language that "makes optional but does not require 
30 steps to be performed." Specifically, if the condition X is true then Y must be 
performed, it is not optional. In Claim 88 the condition is the availability of the 
requestor. In practice there will be times when the requestor is available and 
there will also be times when the requestor is not available. The availability is not 
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under the control of an entity practicing the steps of Claim 88. At those times 
when the requester is "unavailable," the steps of "then waiting until a time the 
requestor becomes available" must be performed. The actor does not have any 
option but to perform these steps. The language is, therefore, not optional. 
5 The section of the MPEP cited by the Examiner makes no mention of "if X 

then Y" language, nor do the Federal Circuit cases cited therein. For example, 
Hofferv. Microsoft (ibid), relates to language that expresses an intended use 
("for" language) and language that expresses an intended result ("whereby" 
language). Neither of these example are in any way related to the "if X then Y" 
10 language of Claim 88. The Examiner's position that conditional language is 

equivalent to optional language, is therefore, unsupported by statute regulation or 
case law. 

In contrast with the lack of support for the Examiner's position in statute, 
regulation or case law, the Applicant is able to cite numerous examples in which 

15 the courts have given full weight to "if X then Y" language. See, for example, 
Altiris, Inc. v. Symantic Corp. 318 F.3d 1363, 1371, 65 USPQ2d 1865, 1871 (Fed 
Cir. 2003), wherein the court held that conditional language in the body of the 
claim indicated that a "transferring" step and an "executing step" should 
necessarily be performed prior to boot up. In the same case at 1 138 the court 

20 states "[t]he only order mandated by the claim language is the conditional 

language in several of the steps, indicating that they must be performed after the 
"testing" step," (emphasis added). The Applicant's position that conditional 
language is, thus, supported in Federal Circuit decisions. 



Brief on Appeal 



13 



Further, assuming for the sake of argument that the Examiner is correct in 
her position that when there is some condition that a step is not always 
performed, then there is no need to show the limitations of that step in rejecting a 
claim. This position would make all conditional claim limitations irrelevant. By 
5 their very nature a claim that includes "if X then Y" suggests that there are some 
conditions under which X is false. The Applicant asks the Board to 
acknowledge that "if X then Y" is a commonly used and accepted structure for 
claim language, and does not represent "optional" language. A search of the 
USPTO database of issued patents (ACLM/'if true then" or ACLMfif false then") 

10 shows that there are 13,668 examples of issued patents that include a "if X then 
Y" structure (where X is limited to the special cases "true" or "false"). If the 
Examiner's position were correct, then any method step that included conditional 
language could be ignored by merely pointing out the case where the condition is 
not satisfied. This is clearly not the case and the Examiner's position, therefore, 

15 cannot be correct. 

(b) whether conditional language, such as if X then Y, can be 
disregarded in rejecting a claim under 35 U.S.C. 102(e). 

20 The Examiner has taken the position that a claim including the claim 

limitations "if the requester is unavailable, then waiting until a time the requestor 
becomes available" can be anticipated by the prior art even if the prior art does 
not teach these limitations because the limitations "are not required." The 
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Applicant takes the position that these limitations must be taught by the prior art 
in order for the Examiner to establish a prima facie case for rejection under 
102(e). 

The requirement that an Examiner point out a prior art teaching of every 
5 limitation in a claim is well established. See for example, MPEP § 2106. II. C 
which states "[w]hen evaluating the scope of a claim, every limitation in the claim 
must be considered," (Diamond v. Diehr, emphasis in original) and MPEP § 2131 
which states a "claim is anticipated only if each and every element as set forth in 
the claim is found." The Examiner's position is directly contrary to these 

10 requirements. 

In contrast, other than MPEM Sec. 21 1 1 .04 discussed above, the 
Examiner has not provided statutory, regulatory or case law support for 
disregarding limitations of Claim 88. As pointed out above, MPEM Sec. 21 1 1 .04 
does not apply to the limitations at issue. 

15 The Examiner argues that there are conditions under which particular 

limitations will not occur so the limitations need not be present in the prior art. In 
response the Applicant respectfully points out that the Examiner's arguments are 
off point. It is immaterial that under particular conditions a particular method step 
will not be performed, as long as they sometimes occur. What is material is 

20 whether the Examiner has presented a prima facie case for rejection. 

In the present application, there are other conditions in which the steps will 
be performed, e.g., the requester sometimes will and sometimes will not be 
available. Under these conditions the cited art clearly does not teach the 
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limitations of the claim. There is no basis that allows the Examiner to pick and 
choose which conditions under which the claim should be considered. The fact 
that there are some conditions under which a method step will occur means that 
the Examiner must find this step in the cited art or allow the claim. 

5 

(c) whether the Examiner has properly interpreted the claim terms 
"requestor becomes available" and "becomes available." 

This issue applies to, for example, Claims 1, 88, 91, 93, 95, and 97, and 
10 those claims that depend therefrom. 
Claim 91 recites: 

91. (Previously Presented) The method of claim 88, further comprising; 

transmitting or receiving a second request for a second real-time meeting 
between a second requestor and the first target, the second request being 
1 5 transmitted or received between a time the first request is transmitted or received 
and a time the first real-time meeting is initiated; and 

initiating the second real-time meeting prior to the first real-time meeting if 
the second requester becomes available before the first requester. 

20 The prior art cited by the Examiner concerns call centers and teaches that 

callers are placed in a call center queue and connected to agents when they 
reach the end of the queue. It appears that the Examiner is reading the teaching 
of a caller reaching the end of the queue as "becoming available." At other times 
that Examiner appears to read the mere presence in a prioritized queue as 

25 teaching both available and unavailable status. Further, it appears to be the 
Examiner's position that reaching the end of a queue teaches becoming 
available. The Applicant traverses these interpretations of the claim terms on at 
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least two grounds. First (a), this interpretation of the claim term "available" 
contradicts the use of the term within the specification and as would be 
understood by one of ordinary skill in the art. Second (b), in the cited art, the 
progression of the queue is a function of the availability of an agent who receives 
5 the call rather than the availability of a caller (requestor). Each of these grounds 
is discussed below. 

(a) There is ample support for the Applicant's position that the claim term 
"availability status" should be interpreted as one of ordinary skill in the art in light 
of the specification. See, for example: 2111.01.11, The ordinary meaning of a 

10 claim term is the meaning that the term would have to a person of ordinary skill in 
the art. Phillips v. AWT Corp. MPEP § 2106. II.C, Office personnel must rely on 
the applicant's disclosure to properly determine the meaning of the claims. 
Markman v. Westview Instruments. MPEP § 21 06. II.C. & 21 1 1 , Office personnel 
are to give claims their broadest reasonable interpretation in light of the 

1 5 supporting disclosure . In re Morris; In re Hyatt. 

Applicant's interpretation of the term "availability" is that a party has the 
ability and/or desire to engage in a meeting. In the specification the term 
"availability" is used, for example, to indicate the general ability or desire of a 
party to engage in a meeting. In various embodiments: a party can be off the 
20 phone but still available: someone may be available before a call is initiated and 
the call initiated when both parties become available; availability may be 
determined using a wide variety of criteria: and a meeting requestor can become 
available and then unavailable multiple times while waiting to have the meeting. 
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These uses of the term "availability" are independent of and contradictory to 
interpreting availability as a position in a call center queue. A requestor 
becoming available is, thus, not taught by advancement in a queue. 

More specifically the specification characterizes "availability," in various 
examples, as follows: 

(i) At paragraph [0009] (US 2003/0191676 A1) the specification 

teaches that in some circumstances availability is determined 
before adding a request to a queue while in other embodiments 
"requests are always queued before availability is determined." 
This shows that the specification treats availability as something 
independent of being placed in queue. 

(ii) At paragraph [0010] availability is taught to be tracked through 

actions such as "pressing buttons on the phone, speaking to the 
phone, knowing when the user is moving and how fast (i.e., the 
difference between walking and driving), knowing if the phone is 
on the user's body (body heat), eventually knowing the user's 
exact location, both to decide availability and to route calls to 
landlines in that exact location." Again, this concept of 
"availability" is not taught by merely position in a queue. 

(iii) At paragraph [0012] the specification teaches that availability "is 

preferably determined based on a variety of factors, including 
whether the user is typing at his computer, whether the user is 
physically in the room, and scheduled periods of availability for a 
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user." These factors are contradictory to the Examiner's position 
that becoming available is determined by reaching the end of a 
queue. Specifically, whether or not a user is typing at a 
computer, the physical location of the user, or a scheduled 
period, have no relation to reaching the end of a call center 
queue. 

(iv) At paragraph [0033] the specification teaches that the software 112 

uses various metrics to decide if a party is available for a call, 
including explicit action (i.e., by the party running a program or 
invoking a function in a running program) and implicit 
measurements such as tracking keyboard and mouse activity, 
noise in the room, phone use, lights, door activity, motion 
sensors (and other devices used by security systems), "electric 
eye" etc." Again, availability decided through these metrics is not 
taught by a position in a call center queue. 

(v) At paragraph [0035] it is taught that a call is initiated only after 

mutual availability has been made. This can either be performed 
by a computer or one of the parties can be ask to manually place 
a call. In contrast, the systems of the prior art require that a 
caller first initiate the call and wait "on hold" in order to stay in the 
call center queue. The position in a queue does not teach an 
availability that is determined before the call is initiated. 
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(vi) At paragraph [0051] it is taught that a user can change from being 

available to being unavailable. This is contrary to the Examiners 
suggestion that reaching the end of a queue is what makes a 
caller available because there is no teaching in the cited art that 
they could be first available, then become unavailable and then 
available again. 

(vii) Paragraphs [0054] - [0080] teach further criteria for determining 

availability, these include but are not limited to: 

[0055] Start or end of call or other use of phone. 

[0056] Off-hook: Unavailable 

[0057] Recently off-hook: Probably available 

[0058] Recent activity at computer input devices (mouse, keyboard 
etc.) 

[0059] Probably available 

[0060] Conversation near microphone 

[0061] Available but possibly in meeting. Possibly Available after 
conversation stops. 

[0062] Lights turned on/off (based on time of day) 

[0063] Possibly available if lights turned on recently and still on. Not 
available after lights off outside daylight hours 

[0064] Weight in chair or on floor 

[0065] Possibly available if sitting in chair 

[0066] Motion sensor triggers/stops triggering 

[0067] Available if recent motion sensed in room 

[0068] (others as needed) 

[0069] Opening/closing of door 

[0070] User may configure "door closed" as a signal of 
unavailability. 

[0071] Spoken commands 

[0072] Simple voice recognition (closest match) on phrases such as 
"hold calls" etc. 
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[0073] Computer keyboard/mouse based commands 

[0074] User may of course set availability state, or even browse 
pending calls using computer interface 

[0075] Touchtone commands 

5 [0076] If system is able to listen to DTMF tones from phone, users 

may prefer to use these to substitute for computer commands. 

[0077] Remote access touchtone commands 

[0078] If user is not at desk but using remote phone interface, 
touchtone codes (and caller ID information from incoming call) to 
10 control system, change location, set availability status. 

[0079] Scheduled periods of availability 

[0080] User may have default periods when they are always 
available unless they signal otherwise or metrics signal otherwise. 
The system may determine his availability by reading the user's 
15 calendar. 

These criteria are all in agreement with the Applicant's interpretation of the 
term "availability" as, for example, to indicate the ability or desire of a party 
to engage in a meeting. In contrast, they are not criteria that would be 
20 used to determine when a caller reaches the end of a call center queue. 

Therefore, the queue of the cited prior art does not teach "availability" as 
used in the specification as filed. Or as would be understood by one of 
ordinary skill in the art. 

(viii) Paragraph [0082] teaches that certain embodiments allow 
25 requesters and targets to specify their availability during a 

predetermined time period, such as the estimated duration of the 
RTM (real-time meetingO. Again, this teaching is in agreement 
with the Applicant's the position and would not make sense if 
"availability" meant position in a queue. 
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(ix) Paragraph [0090] teaches that several messages can have mutual 

availability and these can be sorted by priority. This shows that 
availability is treated differently from priority, is in agreement with 
the Applicant's use of the term "availability" and that availability is 
determined independent of a queue position. 

(x) Paragraph [0133] teaches that a user may become available when 

a call in which the user is engaged ends. This would not be 
possible if "availability" meant merely position in a queue but is in 
agreement with the Applicant's interpretation of the term 
"availability." 

(xi) Paragraph [0237] teaches that a user can have an accidental status 

of available or unavailable. This would not be possible if 
"availability" meant merely position in a queue but is in 
agreement with the Applicant's interpretation of the term 
"availability." 

(xii) Further, several of the claims as filed provide examples of 

"availability" that is certainly not taught by a position in a queue. 
For example, in Claim 19 as originally filed includes criteria for 
determining the highest priority request. One of these criteria is 
the "expected remaining time of availability." In Claim 20 as 
originally filed the determination of "availability of a user" is 
taught to include monitoring the activity of a user to determine 
whether the user is physically present; and displaying at least 
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one request identifying a requestor..." In Claim 24 as originally 
filed a determination of whether the user is physically present is 
"is made by checking one or more of: start or end of a call; other 
use of phone; recent activity at computer input devices; 
conversation near microphone; lights turned on/off; weight in 
chair or on floor; a motion sensor; opening/closing of door; 
spoken commands; computer keyboard/mouse based 
commands; touchtone commands; and scheduled periods of 
availability." In Claim 26 as originally filed it is taught that "a 
determination of availability is made by monitoring the activity of 
the user's environment." All of these example, are in agreement 
with the Applicant's position as to the interpretation of the term 
"available" but, are clearly not in agreement with a position that 
"availability" is merely a call center queue position. 

(b) Second, in rejecting Claim 91 the Examiner suggests that figures 2-3, 
column 3, lines 1-20, column 5, lines 20-40, column 6 lines 35-45, or column 7, 
lines 1-15 and 35-50, teach the limitations "initiating the second real-time meeting 
prior to the first real-time meeting if the second requester becomes available 
before the first requester " More specifically, the text cited by the Examiner 
teaches the progression of a caller to first position a call center queue and the 
Examiner suggests this teachings "the ... requester becomes available." The 
Applicant traverses these suggestions. 



Brief on Appeal 



23 



09/416,278 



The Application believes that the position of the Examiner is incorrect 
because in the system of Gisby the requestor (caller) is always available while 
they are waiting in the queue and also because advancement in the queue is a 
function of the status of the target not the requestor. 

5 Specifically, in Gisby a caller waits in a queue at a call center waiting for 

an agent to become available. The caller is on hold and waiting on the phone 
while in the queue. It is the position of the Applicant that a caller waiting on hold 
would always be considered "available." They are, after all, waiting on hold to be 
connected and presumably would like to be connected as soon as possible, as 
10 such, they are "available." It is unclear how a person waiting on hold could be 
considered unavailable. Typically, they would like to engage in the meeting as 
soon as possible. The caller in Gisby is, therefore, always available while waiting 
in the queue and advancement to the first position in the queue cannot teach "the 
... requester becomes available." 

1 5 The claim limitations "initiating the second real-time meeting prior to the 

first real-time meeting if the second requester becomes available before the first 
requester," and where "the second request being transmitted or received 
between a time the first request is transmitted or received and a time the first 
real-time meeting is initiated" require in combination that the order in which 

20 requests are received is different than the order in which requesters become 
available. 

However, in Gisby the requestors become available at the time each 
request is made (e.g., when they call the call center) and they are placed in the 



Brief on Appeal 



24 



queue (put on hold). As such, the order of availability is the same as the order of 
requests. The Applicant is unable to identify any teaching that the order in which 
real-time meetings are requested is not the same as the order in which 
requestors become available, particularly where that order of availability is 
5 different than the order in which requests were made as recited in Claim 91 . As 
such, the cited art does not teach "initiating the second real-time meeting prior to 
the first real-time meeting if the second requester becomes available before the 
first requester " as recited in Claim 91. 

Further, the Applicant is unable to identify any teaching of an unavailable 
10 requestor in a queue within Gisby. Specifically, there is no mechanism for them 
to become unavailable and then available again. Further, as requestors are 
available when they first join the queue there does not appear to be any 
mechanism taught that would allow them requester to become unavailable and 
then available again while in the queue. In Gisby, it appears that requesters are 
15 assumed to always be available if they are in the queue. As such, there is no 
way for the second requestor to become available before the first requestor and 
the cited art does not teach ''initiating the second real-time meeting prior to the 
first real-time meeting if the second requester becomes available before the first 
requester," as recited in Claim 91. 

20 Further, in Gisby a caller advances in the queue as agents finish their calls 

and are ready to serve the next caller in the queue (Figures 2-3). As such, 
advancement in the queue is representative a change in state of the agent rather 
than that of the caller. The teachings cited by the Examiner therefore are more 
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properly interpreted as teaching an agent becoming available rather than a caller 
becoming available. 

Column 3, lines 1-20 of Gisby teach a process by which calls of higher 
priority may bump calls of lower priority. These teachings, thus, do not appear to 
5 be related to requestors becoming available, rather in these teachings, it is call 
center agents not requestors that become available and unavailable. Requestors 
always appear to be available, although some may have different priorities than 
others. The Applicant is unable to identify any teaching that the order in which 
real-time meetings are initiated is dependent on the order in which requestors 
10 become available, particularly where that order is different than the order in 
which requests were made. 

Column 5, lines 20-40 of Gisby teach the priority and bumping system of 
Figure 3. As discussed above, these teachings appear to be dependent on the 
availability of agents rather than the availability of requesters. Further, they do 
15 not teach that the order in which real-time meetings are initiated is dependent on 
the order in which requestors become available, particularly where that order is 
different than the order in which requests were made. 

Column 6 lines 35-34 teach actions based on the availability of agents 
rather than requesters. 

20 Column 7 lines 1-15 and 35-50 teach actions based on the availability and 

capability of agents rather than requesters. 
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The Applicant is, thus, unable to identify any teaching in the cited art of 
initiating the second real-time meeting prior to the first real-time meeting if the 
second requester becomes available before the first requester" and where "the 
second request being transmitted or received between a time the first request is 
5 transmitted or received and a time the first real-time meeting is initiated" as 
recited in Claim 91 . The Applicant, therefore, requests that the Examiner point 
out teachings of these limitations within the cited art with particularity, or allow 
Claim 91. 



10 (d) whether the cited art teaches having an available target, waiting 

for a requester to become available, when the requester becomes 
available finding that the target is no longer available and having 
to wait for the target to become available. 



15 Claim 89 recites: 

89. (Previously Presented) The method of Claim 88, further comprising: 
in response to the requester becoming available, determining if the first 
target is still available; 

if the first target is still available, then initiating the first real-time meeting; 

20 and 

if the first target is unavailable, then waiting until the first target becomes 
available. 

It is the position of the Applicant that the Examiner has not properly 
25 pointed out teachings of these limitations in the prior art as required to establish a 
prima facie case for rejection under 35 U.S.C. 102. The Applicant looks forward 
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to the Examiner either pointing out such teachings in the Examiner's Answer, or 
withdrawing the rejection of Claim 89. 



II. Whether Claims 1. 3-8, 54-55, 72-79, 81-82, 84-85 and 87 were properly 
5 rejected under 35 U.S.C. 103(a) as being unpatentable over Gisby et al. (US 
6,044,146) in view of Yacenda et al. (U.S. 5,515,426). 

(a) whether the Examiner has properly interpreted the claim terms 

"availability status." 
Claim 1 recites: 

10 

1. (Previously Presented) A computer-implemented method for the 
intermediation of real time meetings, comprising: 

receiving an indication by a requester system that a requester (R-A) wants 
to request a realtime meeting M-A with a target T-A; 
15 sending to a decider system (D) a request to conduct a real time meeting 

M-A; 

queuing the request for the meeting M-A by the decider system; 

receiving by the decider system (D) an availability status of T-A; 

receiving by the decider system (D) an availability status of R-A, where a 
20 possible availability status includes not available; 

receiving an indication by the requester system that a requester (R-B) 
wants to request a realtime meeting M-B with target T-B, the meeting M-B to be 
disjoint in time with the meeting M-A; and such that one of the parties to M-A (R- 
A or T-A), known as the 'common party' is also the same as one of the parties to 
25 M-B (R-B or T-B) and thus there are three distinct parties, the decider D being 
associated with the common party; 

sending to the decider system (D) a request to conduct a real time 
meeting M-B; 

queuing the request for the meeting M-B by the decider system, such that 
30 requests for at least two distinct meetings, disjoint in time are placed in the 

queue, so that multiple pending real time meetings for the common party are in 
the queue at the same time; 

receiving by the decider system (D) an availability status of target T-B; 

receiving by the decider system (D) an availability status of the requester 
35 R-B, where a possible availability status includes not available; 

initiating, by the decider, one of the two meetings M-A and M-B by 
connecting the common party and the other party to that meeting when the 
common party and that other party are mutually available: and 
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dequeuing the request for a meeting. 

In the rejection of Claim 1, the Examiner appears to believe that 
"availability status" is taught by merely a priority ranking among requesters, while 
the Applicant disagrees. The Board is referred to the Applicant's arguments 
above with respect to Claims 1 , 88 etc. as to the meaning of "availability." 

(b) whether the Examiner has properly interpreted the claim term 
"availability status," where "availability status" includes "not 
available." 

While the discussion of the term "availability status" is discussed above 
with reference to Claim 88, in Claim 1 the term is further characterized as 
including "not available." This further characterization is discussed here. 

In the rejection of Claim 1 , the Examiner appears to believe that 
"availability status" where one of the possible statuses includes "not available" is 
taught by merely a priority ranking among requesters. 

It is the position of the Applicant that a teaching of a prioritization does not 
teach an availability status that includes "not available." Priority is a relative 
ranking between objects (callers of Gisby) in which one object can have a greater 
priority than another object. In contrast "not available" a unitary state 
independent of the states of other objects. The Examiner has failed to provide 
an explanation of how a priority ranking among callers teaches an availability 
status that includes "not available." 
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Further, in Gisby, all requestors appear to be available while in the queue 
even though they may have different priority. Thus, the terms "priority" and 
"availability" clearly have different uses and meanings in the cited art, and 
"priority" does not teach "availability." 
5 Further, the terms "priority" and "availability" clearly have substantially 

different dictionary definitions. For example: 

The American Heritage dictionary of the English Language, Fourth Edition 
(2006) defines "priority" as: 

1 . Precedence, especially established by order of importance or urgency. 

10 2. 

a. An established right to precedence. 

b. An authoritative rating that establishes such precedence. 

3. A preceding or coming earlier in time. 

4. Something afforded or deserving prior attention. 

15 

The same dictionary defines "availability" as: 

1 . Present and ready for use; at hand; accessible: kept a fire extinguisher 
available at all times. 

2. Capable of being gotten; obtainable: a bedspread available in three 
20 colors. 

3. Qualified and willing to serve or assist: a list of available candidates; 
was not available for comment. 

4. 

a. Chemistry Capable of being used in a chemical reaction: 
25 available electrons. 

b. Botany Present, as in soil, and capable of being used by plants 
as a nutrient: available water; available minerals. 

c. Capable of bringing about a beneficial result or effect. 

d. Law Valid. Used especially of a plea. 

30 

The Applicant is unable to identify any commonality between these 
definitions that would allow the Examiner to suggest that "Priority" teaches 
"Availability." 
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Finally, the Board is referred to the specification as filed which clearly treat 
the status of a requester and the priority of a request as different things. See for 
example Paragraph [0012] which teaches the separate determination of 
availability and priority. The examples provided in this paragraph of factors to be 
5 used in these determinations are mutually exclusive. See also Paragraph [0136] 
which teaches the display of priority and availability to a user. In this paragraph 
priority and availability are treated as separately displayable objects. 

For at least the above reasons, "priority" and "availability" are distinctly 
different things and a teaching of "priority" does not anticipate a claim limitation of 
10 "availability." 



(c) whether the Examiner has properly interpreted the claim term 
"not available" in the claim element "receiving by the decider system 
(D) an availability status ofR-A, where a possible availability status 
1 5 includes not available." 



The Examiner suggests Figures 24A and 24B, column 17 line 55-column 
18, line 5 and column 19 lines 32-55 of Gisby teaches "wherein a callback 
function is indicated, the party to the called back (the requester) is unavailable, 
20 and the meeting does not occur until both parties are available." The Applicant 
traverses this statement. 

The specification as filed explicitly teaches examples of a requestor 
hanging up and still being available. See for example, paragraph [0056] which 
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teaches "Recently off-hook: Probably available" as a criteria for determining 



availability. Thus, the fact that a requestor has hung up, in the cited art, does not 
necessarily teach that the requestor is "unavailable," and the art cited by the 
Examiner does not teach "a possible availability status includes not available," as 
5 recited in Claim 1 . 

Assuming for the sake of argument, that placement of the requestor on a 
call back list and the requestor hanging up represented unavailability of the 
requestor, there would be no way in the teachings of Gisby to recover from this 
state. Specifically, once the requestor hung up there would be no way for the 
10 system to determine when the requestor became available again and can receive 
the callback. 

Further, the Applicant has now twice previously argued: 

In rejecting Claim 1 the Examiner states "Yacenda et al. discloses 
that the requestor (who called an unavailable target party) leaves his/her 

15 number for callback and then when the target party becomes available, 

the requestor is no longer available (and thus his /her status is 
unavailable)." The Applicant traverses this statement. 
Those parts of Yacenda cited by the Examiner teach determining if a 
called party is unavailable. See, for example, step 1910 in Fig. 24. In the 

20 context of Claim 1 , the called party would be the target and the caller 

would be the requester. Thus, the unavailability that is determined in 
Yacenda is again that of the target not a requestor. (Emphasis in original) 

The Examiner does not appear to have responded to this argument. The Board 
25 is reminded that the Examiner must respond to these arguments. Specifically, 
MPEP §707. 07(f) is entitled "Answer All Material Traversed" and states "[w]here 
the applicant traverses any rejection, the examiner should, if he or she repeats 
the rejection, take note of the applicant's argument and answer the substance of 
it." The Applicant, therefore, again requests that the Examiner point out a 
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teaching of "receiving by the decider system (D) an availability status of R-A, 
where a possible availability status includes not available" where it is the 
availability of the requester that is received, or allow Claim 1 and those claims 
that depend therefrom. The Applicant looks forward to a rebuttal to these 
5 arguments in the Examiner's answer. 

Further, the Applicant has now twice previously argued: 



In the teachings of Yacenda the caller presumably hangs up after setting 
up the call back options. This action does not necessarily make the caller 

10 unavailable in some embodiments of the current invention. A caller can 

hang up and still be available. Availability is with regard to whether a party 
is ready to join in a meeting (e.g., call) and not whether they are holding 
on the line. See for example, page 3 lines 3-6, and page 6 line 12 through 
page 7 line 6 of the current specification as filed. To suggest that the 

15 caller hanging up teaches receiving an availability status of not available 

would be interpreting the term availability status in a manner that is 
contradictory to the specification. 



The Examiner does not appear to have responded to this argument. The 
20 Applicant requests that the Examiner do so or allow Claim 1 , and those claims 
that depend therefrom. The Applicant looks forward to a rebuttal to these 
arguments in the Examiner's answer. 



(d) whether an "availability status" specified as being "one of in, out, 
25 and unknown" is taught by a teaching of "priority." 



Claim 55 recites: 



55. (Previously Presented) The method of claim 54. wherein the 
availability status is one of in, out, and unknown. 
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In rejecting Claim 55 the Examiner again suggests that the teaching of 
"priority" teaches "availability status." In response the Applicant previously 
pointed out that, in Claim 55, the "availability status" is specified as being "one of 
in, out, and unknown." The Applicant also pointed out that it would not make 
5 sense for a priority to be "one of in, out, and unknown." 

The Examiner does not appear to have responded to this argument. The 
Applicant, therefore, again requests that the Examiner specifically point out how 
a teaching of priority teaches an "availability status" of "in," "out" and "unknown" 
as required to support a prima facie rejection under 103(e). 

10 

(e) whether there is not proper motivation to combine the art as 
required to establish a prima facie case for rejection under 35 U.S. C. 
103(a), because the combination of prior art suggested by the 
Examiner would produce a non-workable system. 

15 

To establish a prima facie case of obviousness, three basic criteria must 
be met. First, there must be some suggestion or motivation, either in the 
references themselves or in the knowledge generally available to one of ordinary 
skill in the art, to modify the reference or to combine reference teachings. 
20 Second, there must be a reasonable expectation of success. Finally, the prior art 
reference (or references when combined) must teach or suggest all the claim 
limitations. The teaching or suggestion to make the claimed combination and the 
reasonable expectation of success must both be found in the prior art, and not 
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based on applicant's disclosure. In re Vaeck, 947 F.2d 488, 20 USPQ2d 1438 
(Fed. Cir. 1991). See MPEP § 2143 - § 2143.03. 

There are several criteria which must be met by the "suggestion or 
motivation" to combine the art. These criteria include: MPEP 2143.02, a 
5 reasonable expectation of success is required. - some degree of predictability; 
MPEP 2143.01 .V, the proposed modification cannot render the prior art 
unsatisfactory for its intended purpose; and MPEP 2143. 01. VI, the proposed 
modification cannot change the principle of operation of a reference. It is the 
Applicant's position that none of these criteria are met by the Examiner's 
10 rejection. 

The Applicant previously argued that the combination suggest by the 
Examiner would result in an unworkable combination. In response the Examiner 
states "Examiner utilized Yacenda et al. to teach the concept that a possible 
availability status of the requestor R-A or R-B includes not available. Examiner 
15 did not really [sic] on Yacenda et al. to disclose the underlying system on which 
the method operates. Yacenda et al. discloses that a requestor disconnects from 
the system and this is unavailable because he/she is no longer in the queue 
waiting to connect with the second party." 

In rejecting under 103, the burden is on the Examiner not merely to show 
20 the teachings of limitations within separate art but to show that these teachings 
would be obvious to combine. The decision in In re Vaeck stands for the point 
that a combination that would not be likely to be successful would not be obvious. 
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The Examiner is combining the teaching of Yacenda, specifically an 
availability status that includes "unavailable," with those of Gisby. However, the 
Applicant points out that Yacenda teaches that the availability status of 
"unavailable" is only available under a specific set of conditions, e.g., that the 
5 requester and target be on the same PBX. (PBX is a local telephone switch.) 
Presence on the same PBX is a requirement for the status of "unavailable" in 
Yacenda. This specific set of conditions is not meet within the system of Gisby. 
Gisby is a call center in which callers are to be expected to call from a wide 
range of locations outside of a single PBX. See for example, column 1 lines 20- 
10 56 and in particular lines 52-56 which discusses pre-routing of calls. Thus, 

according to the requirements of Yacenda, it would not be possible to include an 
availability status that includes "unavailable," within a system such as that of 
Gisby because Gisby includes more than a single PBX. 

To adapt the teachings of Gisby to incorporate the teachings of Yacenda 
15 would require a "change in the principle of operation of Gisby," e.g., it would 
require all callers to be on the same PBX. Without this change Gisby would no 
longer be satisfactory for its intended purpose. Specifically, it would not make 
sense to have a call center that could only handle calls from a single PBX. The 
combination suggested by the Examiner, therefore, does not meet the criteria 
20 required by MPEP 2143.02, MPEP 2143.01 V and MPEP 2143.01 VI discussed 
above. As such, it is the position of the Applicant that the Examiner has not 
presented a prima facie case for the rejections under 35 U.S. C. 103(a) 
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In response to the Examiner's statement that "Examiner utilized Yacenda 
et al. to teach the concept that a possible availability status of the requestor R-A 
or R-B includes not available. Examiner did not really [sic] on Yacenda et al. to 
disclose the underlying system on which the method operates," the Applicant 
5 points out that while Yacenda need not disclose the "underlying system," the 
teaching to be combined with Gisby must at least work within the system of 
Gisby. As pointed out above, this is not the case. 

(f) whether the Examiner has properly interpreted the claim term 
10 "polled" as recited in Claims 3 and 5. 

In rejecting Claim 3 the Examiner suggests that the polling of target T-A is 
taught by a teaching of "column 5, lines 5-1 1 , wherein the system knows if the 
target is logged in and busy." In response to the Applicant's arguments that the 

15 cited art does not teach polling, the Examiner states "the term poll means to 
survey in the broadest reasonable interpretation of the term." The Applicant 
traverses this statement. 

According to MPEP § 2111.01.11, the ordinary meaning of a claim term is 
the meaning that the term would have to a person of ordinary skill in the art. 

20 Phillips v. AWT Corp. It is the position of the Applicant that one of ordinary skill 
in the art would equate the term "poll" with the term "survey." Rather, in the arts 
of computer science and communication the term "poll" has a much more specific 
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meaning. For example, the Microsoft Computer Dictionary 5 th Ed. defines polling 



The process of periodically determining the status of each device in a set 
so that the active program can process the events generated by each 
5 device, such as whether a mouse button was pressed or whether new 

data is available at a serial port. This can be contrasted with event-driven 
processing, in which the operating system alters a program or routine to 
the occurrence of an event by means of an interrupt or message. 



10 Likewise, the Encyclopedia of Technology Terms (Que press 2001) 

defines polling as: 

In electronic communication, 'polling' is the continuous checking of 
other programs or devices by one program or device to see what 
state they are in, usually to see whether they are still connected or 
1 5 want to communicate. 

Specifically, in multipoint or multidrop communications (a controlling 
device with multiple devices attached that share the same line), the 
controlling device sends a message to each device, one at a time, 
20 asking each whether it has anything to communicate (in other 

words, whether it wants to use the line). 



These definitions are provided merely for the purposes of example. 
However, they characterize polling as a specific type of communication mode to 
25 which there alternatives. The Applicant is unable to identify any teaching in the 
cited art that Gisby uses the specific type of communication included in "polling," 
rather than one of the alternatives. 

The Applicant respectfully points out that the Examiner now has the 
burden of either accepting these definitions for the term "poll," or to provide 
30 rebuttal evidence. 
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The Applicant is unable to identify any teaching within Gisby that fit within 
the term polling as used in communications and computer science. Therefore, 
Gisby does not teaching "wherein a system of the target T-A is polled to 
determine the availability of target T-A." as suggested by the Examiner. 

5 

(g) whether the cited art teaches pushing of status information to the 
decider system by the Target T-A (claim 4) or by the party (claim 6). 

Claim 4 recites: 

10 4. (Previously Presented) The method of claim 1, wherein the system of 

the target T-A pushes the availability status of target T-A to the decider 
system. 

Claim 6 recites: 

15 6. (Previously presented) The method of claim 1, wherein the system of a 

party pushes the party's availability status to the decider system. 

In rejecting Claims 4 and 6 the Examiner states "Gisby et al. teaches 

wherein the system of a party pushes party's availability status to the decider 

20 system (See column 5, lines 5-11, column 7, lines 1-15 and 30-50, wherein the 

system knows if the target is busy based on status information established by the 

target)." The Applicant traverses this statement. 

Column 5 lines 5-1 1 teach "[t]he status of telephones at agent stations is 

also monitored, so the application has access to real-time information as to which 

25 logged-in agents are busy on a call and which are not. ..." Column 7 lines 1-15 

teach "an agent residing at agent station 33 may be reported busy because he is 
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answering E-mails and cannot be interrupted by a telephone call unless it is of 

priority 7 or above " Column 7 lines 30-50 teach "[an agent's] status was 

made available to reporting software via a database so that no calls 
"availability status of agent such as agents 1-4 will change in real time...," and 
5 "Agent 4 is reported busy. . . " 

First, while the cited art teaches "monitoring," "reporting" or making 
"available" of status information, the Applicant is unable to find any teaching that 
this includes pushing by a target system the availability status of the target to a 
decider system (Claim 4) or pushing by a party system the availability status of 
10 the party to the decider system (Claim 6). Specifically, the Applicant is unable to 
identify any teaching that information is "pushed" rather than being 
communicated by some other means, for example pulling. 

The term "push" has specific meaning in the field of computer science. 
For example, Barron's "Dictionary of Computer and Internet Terms" (8 th ed. 2003) 
15 Defines pushing as "the process whereby the network delivers information to a 
client machine without waiting for the user to request it... (contrast PULL)." 

This definition is provided merely for the purposes of example. However, 
it characterizes pushing as a specific type of communication mode to which there 
alternatives, e.g., pulling. The Applicant is unable to identify any teaching in the 
20 cited art that Gisby uses the specific type of communication included in 
"pushing," rather than one of the alternatives. 
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(h) whether or not the limitations of Claim 78 require that a caller is a 
party to more than one request. 

Claim 78 recites; 

5 78. (Previously Presented) The method of claim 1, wherein a non- 

common requester R-A or R-B is party to another, distinct meeting 
request. 

The Applicant believes that the limitations of Claim 78 require that a caller 
10 be a party to more than one meeting request. The Examiner believes that the 
limitations of Claim 78 do not require that a caller be party to more than one 
meeting request. The Applicant and the Examiner appear to agree that if Claim 
78 did require that the caller be a part to more than one meeting request, then 
the cited prior art would not anticipate Claim 78. 

15 To clarify: 

(a) By characterizing the requestors R-A and R-B as non-common, then T-A 
and T-B must be the common party because as recited in Claim 1 , at least 
one of (R-A and R-B) or (T-A and T-B) are common. 

(b) As such the requests recited in Claim 1 by R-A and R-B must be made to 
20 the same common target. 

(c) These requests by R-A and R-B are not distinct because they are directed 
at the same target. 

(d) The language of Claim 78 states that one of the requestors is "party to 
another, distinct meeting request." 
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(e) This other distinct meeting request cannot be one of the requests recited 
in Claim 1 because these requests, as discussed above are not distinct. 

(f) Therefore, at least one of R-A and R-B must be a party to an additional 
request that other than those recited in Claim 1 . 

5 (g) The request recited in Claim 1 plus the additional request not recited in 
Claim 1 makes two requests and that requestor must be a party to more than one 
request. 

Finally, the cited art does not show that one of the requestors R-A and R-B is 
a party to more than one distinct meeting request and Claim 78 is not anticipated 
10 by the prior art. 



(i) At issue in the rejection of Claim 84 is the feasibility of combining 
the cited art with official notice taken by the Examiner. 



15 Claim 84 recites: 

84. (Previously Presented) the method of claim 1, wherein the target is a 
specific individual selected by the requestor. 

The Examiner expressly admits that "[njeither Gisby et al. nor Yacenda et 
20 al. expressly disclose that the target is a specific individual selected by the 
requestor." The Examiner further "takes official notice that it is old and well 
known in the telephone art for a calling party to request a specific individual when 
placing a call to a second organization, such as when a person calls a company 
and asks to speak with a certain manager." The Examiner is suggesting that the 
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system of Gisby be modified to allow a requestor to select a specific one of 
Agents 1-4 of Gisby et al. 

It is the Applicant's position that such a modification is in direct 
contradiction to the teachings of Gisby. As such, the art teaches away from the 
5 Examiners suggested modification. As noted above, according to the MPEP, the 
proposed combination cannot render the prior art unsatisfactory for its intended 
purpose; and cannot change the principle of operation of a reference. As such 
the proposed combination and the rejection under 103(a) lacks proper 
motivation. 

10 Gisby is quite specific that "[destinations, in the call center agent stations 

are selected on a basis of agent availability," (abstract). This "maximizes 
efficiency of call centers," (Col. 3 lines 25-26). The modification suggested by 
the Examiner would cause agents to be selected on a basis other than that of 
availability because the selection would have to be made before the agent 

15 becomes available. This is a change in the principle of operation of Gisby and 
contradicts the teachings of the cited art. Further, it is a goal of Gisby to 
"maximize[s] efficiency of call centers. To allow callers to select specific targets 
ahead of time would reduce the efficiency of call centers because agents would 
no longer be assigned to calls on the basis of agent availability. Thus, the 

20 modification suggested by the Examiner is contrary one of the primary goals of 
Gisby and Gisby could no longer achieve one of its intended purposes (efficiency 
maximization). 
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As such, the combination suggested by the Examiner do not satisfy the 
required criteria. Specifically, the combination does not satisfy: MPEP 
2143. 01. V, the proposed modification cannot render the prior art unsatisfactory 
for its intended purpose; and MPEP 2143. 01. VI, the proposed modification 
5 cannot change the principle of operation of a reference. The Examiner has, thus, 
failed to present a prima facie case for rejection under 35 U.S.C. 103(a). 

III. Claims 56-57 and 80 were rejected under 35 U.S.C. 103(a) as being 
unpatentable over Gisby in view of Yacenda and in further view of Vaios 
10 (U.S. 6,272,216. 

(a) At issue in the rejection of Claim 56 is whether the addition of the 
teachings of Vaios to those of Gisby would produce a result that is 
contrary to the teachings of Gisby, and there would, therefore, not be 
a proper motivation to make the combination. 

15 

Claim 56 recites; 

56. (Previously Presented) The method of claim 1, further comprising 
displaying an availability status of the target T-A on the requester system, 
along with an indication that the requestor has requested a meeting with 
20 the target. 

In rejecting Claim 56 the Examiner states it "would have been obvious to 

one of ordinary skill in the art ... also allow the requester system to view 

availability data and meeting requests by the requester in order to more 

25 efficiently let the requester gain service in a more timely manner The 

Applicant traverses this statement. 
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It is the position of the Applicant that the combination of Vaios and Gisby 
does not have a reasonable expectation of success because those features of 
Vaios used to display the availability status of a target (agent) are not possible in 
Gisby. Further, adding these features to Gisby would be directly contrary to the 
5 proposes of Gisby. As such, the combination does not satisfy the criteria: the 
combination does not satisfy: MPEP 2143. 01. V, the proposed modification 
cannot render the prior art unsatisfactory for its intended purpose; and MPEP 
2143. 01. VI, the proposed modification cannot change the principle of operation 
of a reference. 

10 Specifically, in Gisby the requestor may be eventually connected with any 

one of the Agents 1-4. Because in Gisby agents are selected on the basis of 
availability it is not known in Gisby which agent the requestor will be connected. 
For example, the target that the requestor is eventually connected to is a function 
of which target becomes available first after the requestor has reached the first 

15 position in the queue. This target is not known before hand. Gisby specifically 
teaches this approach. For example, Gisby is quite specific that "[destinations, 
in the call center agent stations are selected on a basis of agent availability," 
(abstract). This "maximizes efficiency of call centers," (Col. 3 lines 25-26). 
In contrast, in Vaios it is known which specific target the requestor will 

20 eventually be connected to well before the connection is made, e.g. while the 
requestor is waiting. In Vaios it is possible to display the availability status of the 
target a requestor will eventually be connected with only because that target has 



Brief on Appeal 



45 



09/416,278 



been specified (by one of many alternative mechanisms) while the requestor is 
waiting. 

To modify Gisby so as to display "an availability status of the target T-A on 
the requester system," as recited in Claim 56, it would be necessary to know 
5 which target the requestor will be connected to while the requestor is waiting. 
This would require that the target is selected before the target becomes 
available. As such the target would be selected on a basis other than agent 
availability. This is contrary to the teachings of Gisby and results in a less than 
maximum efficiency of call centers and, thus, eliminates one of the purposes of 
10 Gisby. 

In order to combine the teaching of Vaios, of displaying the availability 
status of the target the requestor will eventually be connected to, with the 
teachings of Gisby, the teachings of Gisby would have to be modified such that 
the target the requestor will eventually be connected to is known in advance. 

15 This is required because otherwise the system would not know which targets 
availability to display. However, as discussed in the above paragraph, such a 
modification would be contrary to the teachings of Gisby and fail to "maximize[] 
efficiency of call centers." 

The proposed modification of Gisby using the teachings of Vaios is, 

20 therefore, contrary to the teachings of the cited art and the rejection under 103(a) 
should be withdrawn as lacking motivation. 
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IV. Claim 83, 86 and 90 were rejected under 35 U.S.C, 103(a) as being 
unpatentable over Gisbv in view of Vaios. 

(a) At issue in the rejection of Claim 83 is whether the cited art 

teaches all of the limitations of Claim 83. 

5 

Claim 83 recites: 

83. (Previously Presented) The method of claim 1, wherein the common 
party is the requestor R-A and R-B and the common party participates in 
both of the meetings M-A and M-B. 

10 

In rejecting Claim 83, the Examiner admits that Gisby "does not expressly 
disclose that the common party is the requestor R-A and R-B and that common 
party participates in both of the meetings M-A and M-B." The Examiner further 
suggests that Vaios teaches that a "requestor has two or more real-time 

15 meetings in the queue, and thus is the common party in both of the meeting[s]..." 
The Applicant traverses this statement. 

The Applicant respectfully points out that none of the art cited by the 
Examiner teaches "and the common party participates in both of the meetings M- 
A and M-B," as recited in Claim 83. "A claim is anticipated only if each and every 

20 element as set forth in the claim is found, either expressly or inherently 

described, in a single prior art reference." Verdeqaal Bros, v. Union Oil Co. of 
California , 814 F.2d 628, 631, 2 USPQ2d 1051, 1053 (Fed. Cir. 1987). As such, 
the cited art does not anticipate Claim 83. 

While Vaios teaches that a requestor may be queued for two meetings, 

25 once a first of the two meetings is initiated the requestor is removed from the 
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queue of the second meeting. As such, Vaios teaches that the requestor 
"participates" in only one of the two or real-time meetings in the queue, not "both" 
as recited in Claim 83. See for example, Col. 6 lines 6-10 of Vaios which state 
"[i]f, however, additional queued requests were spawned as part of a multiple- 
agent or multiple-resource request on behalf of this caller, then at step 424, all of 
the remaining pending requests are deleted from the system." Thus, once the 
first meeting is established all other pending requests are cancelled and a 
second pending meeting does not occur. The requestor never participates in the 
second meeting and the claim limitations are not taught in the prior art. 

V. Claims 92-92 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Gisbv et al. in view of Yacenda and in further view of Vardi. 

(a) At issue in the rejection of Claim 92 is whether the Examiner has 
failed to present a prima facie case for rejection under 103(a) 
because the prior art does not teach or suggest all the claim 
limitations. 

Claim 92 recites: 

92. (Previously Presented) The method of Claim 78, wherein the non- 
common requester R-A or R-B that is party to another distinct meeting 
request is a target in that meeting request. 

To establish a prima facie case of obviousness, three basic criteria must 
be met. First, there must be some suggestion or motivation, either in the 
references themselves or in the knowledge generally available to one of ordinary 
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skill in the art. to modify the reference or to combine reference teachings. 
Second, there must be a reasonable expectation of success. Finally, the prior art 
reference (or references when combined) must teach or suggest all the claim 
limitations. The teaching or suggestion to make the claimed combination and the 
5 reasonable expectation of success must both be found in the prior art, and not 
based on applicant's disclosure. In re Vaeck, 947 F.2d 488, 20 USPQ2d 1438 
(Fed. Cir. 1991). See MPEP § 2143 - § 2143.03. 

In rejecting Claim 92 the Examiner suggests that column 7 line 50 thru 
column 8 line 5 teach "wherein the requestor of the conference becomes the 
1 0 target of a callback or someone to be conference in." 

The text cited by the Examiner teaches: 

User 10 may alternatively send a request, typically via the Internet, to an 
operator or an automatic telephone switch 28 to initiate two calls, one to 
user 10 and one to user 12, and conference the two calls using known 

15 conferencing means. User 10 typically can configure his client software to 

send the telephone numbers for himself and for user 12, or other means of 
identifying user 10 and user 12, in addition to billing information indicating 
who should be billed for the call, along with proper authorization. User 10 
may request a conference call with more than one user by sending 

20 multiple telephone numbers and/or identifiers in this manner. User 10 may 

additionally indicate if a conference call is to be tried immediately, with 
calls to be conferenced-in as the specified telephone numbers become 
available, or tried only when all the telephone numbers requested for a 
conference are known to be available, such as through requesting the 

25 status of the telephone numbers as described hereinabove. User 1 0 may 

also initiate a call back, delivering his telephone number and availability to 
an automated switch, to be conferenced with one of the switch's outgoing 
dialing lines. User 10 may additionally indicate if a call back is to be tried 
immediately or tried only when the telephone number with which the call 

30 back is concerned is known to be available, such as through requesting 

the status of the telephone number as described hereinabove. 
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While this text teaches callbacks and conference calls, these are not 
examples of a "distinct meeting request" as recited in Claims 78 and 92. 
Specifically, the callback and conference calls taught are both for the purpose of 
completing the original request and involve the same parties. They are, 
therefore, in response to the original request and are not distinct meeting 
requests. 

The cited art, therefore, does not teach all the limitations of Claim 92 and 
Examiner has failed to present a prima facie case for rejection under 103(a) 
because the prior art does not teach or suggest all the claim limitations. 

(b) At issue in the rejection of Claim 93 is whether the cited art 
teaches all of the limitations of Claim 93, specifically, whether Vardi 
et al. teaches "wherein the requestor R-A changes states from not 
available to available, while waiting for the realtime meeting M-A," as 
recited in Claim 93. 

Claim 93 recites: 

93, (Previously Presented) The method of Claim 1, wherein the requestor 
R-A changes states from not available to available, while waiting for the 
realtime meeting M-A. 

In rejecting Claim 93 the Examiner states "Vardi et al. discloses the state 
of parties changing while waiting for a meeting, beginning with being unavailable, 
and ending available (See column 7, line 50-column 8 line 5), wherein the 
conference member is unavailable and becomes available." 
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The cited text (quoted above in the discussion of Claim 92) does teach 
that the target of a meeting request changes states from not available to 
available. However, Claim 93 specifically recites that it is the "the requestor R-A" 
that changes states from not available to available, while waiting for the realtime 
5 meeting M-A." A teaching of a target changing state does not anticipate a claim 
that recites that a '' requestor ' changes state. As such, the cited art does not 
teach all the limitations of Claim 93. 

(c) At issue in the rejection of Claim 94 is whether the art cited by the 
10 Examiner includes all the limitations of Claim 94, specifically 

"wherein the requestor R-A participates in another distinct realtime 
meeting." 

Claim 94 recites: 

15 94. (Previously Presented) The method of Claim 1, wherein the requestor 

R-A participates in another distinct realtime meeting while waiting for the 
realtime meeting M-A. 

In rejecting Claim 94, the Examiner states "Vardi et al. discloses teaches 
20 the requestor R-A participates in another distinct real-time meeting while waiting 
for a meeting M-A (see column 7, line 50-column 8, line 5 wherein the requestor 
involves himself in another meeting while waiting for the other target to 
conference in). The text cited by the Examiner is quoted above in the discussion 
of Claim 92. 
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The text cited by the Examiner concerns the establishment of a 
conference call, in one instance a conference call can be "tried immediately, with 
calls to be conferenced-in as the specified telephone numbers become 
available." However, the Applicant points out that meeting with a first target while 
5 waiting for a second target to join in to the meeting does not constitute "another 
distinct realtime meeting," as recited in Claim 94. The conference call is a single 
meeting at which different people may join at different times. Even if, for the 
sake of argument, the conferencing-in of a second target were to be considered 
a second meeting, this meeting would not be " distinct because it is still part of 
10 the same telephone call. 

For at least these reasons, the text cited by the Examiner does not teach 
all of the limitations of Claim 94, and the Examiner has failed to provide a prima 
facie case for the rejection of Claim 94. 
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Conclusion 

In view of the above remarks, the pending claims in this application are 
believed to be in condition for allowance 
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(9) Appendix A -Listing of Claims 

1 . (Previously Presented) A computer-implemented method for the 
intermediation of real time meetings, comprising: 

receiving an indication by a requester system that a requester (R-A) wants to 
request a realtime meeting M-A with a target T-A; 

sending to a decider system (D) a request to conduct a real time meeting M-A; 

queuing the request for the meeting M-A by the decider system; 

receiving by the decider system (D) an availability status of T-A; 

receiving by the decider system (D) an availability status of R-A, where a 
possible availability status includes not available; 

receiving an indication by the requester system that a requester (R-B) wants to 
request a realtime meeting M-B with target T-B, the meeting M-B to be disjoint in time 
with the meeting M-A; and such that one of the parties to M-A (R-A or T-A), known as 
the 'common party' is also the same as one of the parties to M-B (R-B or T-B) and thus 
there are three distinct parties, the decider D being associated with the common party; 

sending to the decider system (D) a request to conduct a real time meeting M-B; 

queuing the request for the meeting M-B by the decider system, such that 
requests for at least two distinct meetings, disjoint in time are placed in the queue, so 
that multiple pending real time meetings for the common party are in the queue at the 
same time; 

receiving by the decider system (D) an availability status of target T-B; 
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receiving by the decider system (D) an availability status of the requester R-B, 
where a possible availability status includes not available; 

initiating, by the decider, one of the two meetings M-A and M-B by connecting the 
common party and the other party to that meeting when the common party and that 
other party are mutually available; and 

dequeuing the request for a meeting. 

2. (Cancelled) 

3. (Previously Presented) The method of claim 1 , wherein a system of the target 
T-A is polled to determine the availability of target T-A. 

4. (Previously Presented) The method of claim 1, wherein the system of the 
target T-A pushes the availability status of target T-A to the decider system. 

5. (Previously Presented) The method of claim 1 , wherein a system of a party is 
polled to determine the party's availability. 

6. (Previously Presented) The method of claim 1, wherein the system of a party 
pushes the party's availability status to the decider system. 

7. (Previously Presented) The method of claim 1 , wherein mutual availability is 
determined by checking the availability of one of the target/requester pairs T-A/R-A and 
T-B/R-B. 

8. (Previously Presented) The method of claim 1 , wherein a request is sent to a 
plurality of targets and mutual availability is determined when the requester and one of 
the plurality of targets is available. 
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9.-53. (Cancelled) 

54. (Previously Presented) The method of claim 1. further comprising displaying 
the availability status of one of the requesters R-A and R-B on the target system, along 
with an indication that one of the requesters R-A and R-B has requested a meeting. 

55. (Previously Presented) The method of claim 54, wherein the availability 
status is one of in, out, and unknown. 

56. (Previously Presented) The method of claim 1, further comprising displaying 
an availability status of the target T-A on the requester system, along with an indication 
that the requestor has requested a meeting with the target. 

57. (Previously Presented) The method of claim 56, wherein the availability 
status is one of in, out, and unknown. 

58. -71. (Cancelled) 

72. (Previously Presented) The method of claim 1 , wherein the decider system a 
part of the system of the common party for whom it is responsible, and wherein the 
decider already knows the status of the common party for which it is responsible. 

73. (Previously Presented) The method of claim 1 , wherein the decider system 
chooses to activate one of two real time meetings, where the parties for both meetings 
are available, based on at least one of: 

ranking information including manual ranking through a user interface presented 
to the common party; 

priority information provided by either party; 
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the order in time in which the requests were made; and 

relationship information about the parties based on party input or past history. 

74. (Previously Presented) The method of claim 1 , wherein the decider system 
chooses to activate one of two real time meetings, where the parties for both meetings 
are available, based on ranking information including manual ranking through a user 
interface presented to the common party. 

75. (Previously Presented) The method of claim 1 , wherein the decider system 
chooses to activate one of two real time meetings, where the parties for both meetings 
are available, based on priority information provided by either party. 

76. (Previously Presented) The method of claim 1 , wherein the decider system 
chooses to activate one of two real time meetings, where the parties for both meetings 
are available, based on the order in time in which the requests were made. 

77. (Previously Presented) The method of claim 1 , wherein the decider system 
chooses to activate one of two real time meetings, where the parties for both meetings 
are available, based on relationship information about the parties based on party input 
or past history. 

78. (Previously Presented) The method of claim 1 , wherein a non-common 
requester R-A or R-B is party to another, distinct meeting request. 
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79. (Previously Presented) The method of claim 1, wherein a non-common 

target is party to another distinct meeting request. 

80. (Previously Presented) The method of claim 1 , wherein each of the three 
systems has requested and has pending requests for two or more real-time meetings in 
the queue. 

81. (Previously Presented) The method of claim 1, wherein if all parties become 
available at once, only one of the meetings M-A and M-B will occur immediately and the 
other meeting will remain queued. 

82. (Previously Presented) The method of claim 1, wherein the common party is 
the target T-A and T-B. 

83. (Previously Presented) The method of claim 1 , wherein the common party is 
the requestor R-A and R-B and the common party participates in both of the meetings 
M-A and M-B. 

84. (Previously Presented) the method of claim 1 , wherein the target is a specific 
individual selected by the requestor. 

85. (Previously Presented) The method of claim 1, wherein the target is a specific 
individual. 
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86. (Previously Presented) The method of claim 1, wherein the common party is 
the requestor R-A and R-B. 

87. (Previously Presented) The method of claim 1 , wherein the target is any one 
of a group of targets. 

88. (Previously Presented) A method comprising: 

transmitting or receiving a first request for a first real-time meeting between a 
requestor and a first target, the requestor and the first target being individuals; 

determining that the first target is unavailable, using a computing system; 

waiting until the first target changes from being unavailable to being available; 

when the first target is available, determining if the requester is available; 

if the requestor is available, then initiating the first real-time meeting; and 

if the requester is unavailable, then waiting until a time the requestor becomes 
available. 

89. (Previously Presented) The method of Claim 88, further comprising: 

in response to the requester becoming available, determining if the first target is 
still available; 

if the first target is still available, then initiating the first real-time meeting; and 
if the first target is unavailable, then waiting until the first target becomes 
available. 
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90. (Previously Presented) The method of claim 88, further comprising: 
transmitting or receiving a second request for a second real-time meeting 

between the first requester and a second target, the second request being transmitted 
or received between a time the first request is transmitted or received and a time the 
first real-time meeting is initiated; and 

initiating the second real-time meeting prior to the first real-time meeting if the 
second target becomes available before the first target. 

91 . (Previously Presented) The method of claim 88, further comprising; 
transmitting or receiving a second request for a second real-time meeting 

between a second requestor and the first target, the second request being transmitted 
or received between a time the first request is transmitted or received and a time the 
first real-time meeting is initiated; and 

initiating the second real-time meeting prior to the first real-time meeting if the 
second requester becomes available before the first requester. 

92. (Previously Presented) The method of Claim 78, wherein the non-common 
requester R-A or R-B that is party to another distinct meeting request is a target in that 
meeting request. 

93. (Previously Presented) The method of Claim 1 , wherein the requestor R-A 
changes states from not available to available, while waiting for the realtime meeting M- 

A. 
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94. (Previously Presented) The method of Claim 1 , wherein the requestor R-A 
participates in another distinct realtime meeting while waiting for the realtime meeting 
M-A. 

95. (Previously Presented) The method of Claim 1, wherein the requester R-A 
becomes available when the requestor R-A terminates a call. 

96. (Previously Presented) The method of Claim 1 , wherein the requester R-A 
and target T-A are both available when they are both off of the phone. 

97. (Previously Presented) A method comprising: 

transmitting or receiving a first request for a first real-time meeting between a 
requestor and a first target, the requestor and the first target being individuals; 

determining that the first target is unavailable, using a computing system; 

waiting until the first target changes from being unavailable to being available; 

when the first target is available, determining if the requester is available; and 

if the requester is unavailable, then waiting until a time the requestor becomes 
available. 

98. (Previously Presented) The method of Claim 88, further comprising: 

in response to the requester becoming available, determining if the first target is 
still available; and 
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if the first target is unavailable, then waiting until the first target becomes 

available. 

1 
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Description 

[0001] This application claims priority under 35 U.S.C. 
§ 119(e) from U.S. Provisional Application No. 
60/104,255 of Bradley S. Templeton, filed October 14, 
1998. 

BACKGROUND OF THE INVENTION 

Field of the Invention 



[0002] The present invention relates generally to pro- 
ductivity tools and, specifically, to a method and appara- 
tus that aid in managing telephone calls and meetings. 

Related Art 

[0003] Most people have experienced the phenome- 
non known as "phone tag." One person calls a second 
person and leaves voicemail. The second person returns 
the call, only to leave voicemail in turn. This sequence is 
repeated over the course of hours or days, leaving both 
callers frustrated by the fact that they have not spoken 
to each other in person. A similar phenomenon occurs 
when two people try to schedule conference calls and 
meetings or when two people try to get together for a 
face to face talk. 

[0004] Even voice mail, faxes, pages, cell phones and 
e-mail have not solved this problem. In fact, they have 
only made it worse. Phone tag for voicemail, faxes and 
pages result in vast amounts of lost time - not just time 
calling and leaving messages, but delays in getting im- 
portant phone calls made. In addition, tremendous time 
is wasted trying to be available for important calls, and 
even more by being interrupted by calls at just the wrong 
time when real work is getting done. 
[0005] WO 98/21870 discloses an apparatus and a 
method for scheduling a telephone call including a cal- 
endar system within a telephone system and having an 
interface means for obtaining information from a calling 
party, calendar data which includes a calendar for a 
called party, and an agent means. The agent means, in 
response to a request to schedule a telephone call with 
a called party, searches the calendar of the called party 
to determine an available slot for the telephone call. After 
confirming that the available slot for the telephone call is 
acceptable for the calling party, the agent means sched- 
ules the telephone call in the available slot of the calendar 
for the called patty. 

[0006] EP 0 557 777 refers to a telecommunications 
system for the connection of communications terminals 
by which it is possible to store a call-back order in the 
system memory at the calling terminal after an unsuc- 
cessful attempt to set up a call between two connected 
communications terminals, which call-back order causes 
the central system controller to carry out an automatic 
call setting up procedure between the relevant commu- 
nications terminate. 



SUMMARY OF THE INVENTION 

[0007] In accordance with the present invention, there 
is provided a method and apparatus to assist in the in- 
s termediation of telephone calls and meetings. The de- 
scribed embodiment of the invention is akin to a light on 
your desk that lights up when the person you are trying 
to reach is in her office and ready to take calls. 
[0008] In this description, the person initially placing a 

'0 request for a connection or call is termed the requester. 
The person he is trying to call, connect to, or meet with 
is called the target It should be noted that the system of 
the target may end up calling the system of the requester 
in response to the requester's initial request Thus, the 

15 terms requester and target refer to the initial requester 
and his target, and do not necessarily identify who ulti- 
mately places a call or initiates a meeting. Both request- 
ers and targets are sometimes referred to herein as "us- 
ers" or "parties" if such usage seems to improve clarity 

so of an explanation. 

[0009] In afirst embodiment, a requester indicates that 
he wants to call, meet with, or otherwise connect with a 
target. Such a call, connection, or meeting is called a 
realtime meeting. His system sends a request to queue 

25 a call to the target' system. If the target is available and 
wants to talk to the requester, a connection is made and 
the users proceed with their communication. Otherwise, 
the request is queued until both users are mutually avail- 
able (or until a quorum is mutually available if there are 

so more than two parties to a meeting). In other embodi- 
ments, requests are always queued before availability is 
determined. 

[0010] In a first embodiment, the system of the users 
communicate directly. In other embodiments, the sys- 

35 terns of the users communicate by way of intermediate 
servers, by way of a central server, or by any other ap- 
propriate method. Telephone calls can be made via a 
telephone system (such as POTS, a wireless system, or 
a cell phone), via Internet telephony, or via some other 

40 appropriate mechanism, (in the case of cell phones, the 
cell phone can act as a data processing system 100, 
keeping track of availability through actions such as 
pressing buttons on the phone, speaking to the phone, 
knowing when the user is moving and how fast (i.e., the 

4 5 difference between walking and driving), knowing if the 
phone is on the user's body (body heat), eventually know- 
ing the user's exact location, both to decide availability 
and to route calls to landlines in that exact location, if 
desired. 

so [0011] Each user can set up priorities for the people 
who call or contact him. Requests from high priority per- 
sons will preferably interrupt the user, even if he is on 
another call. Requests from lower priority users will be 
queued. Alternately, requests from high priority persons 

55 will be flagged. Users can also rate other users. In em- 
bodiments where rating is enabled, the user and system 
can use the rating of the caller to prioritize, accept, or 
reject the request. The user can see ratings based on 
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his own entries or ratings based on everyone who has 
rated an individual. 

[0012] If a user is unavailable when a call is received, 
a request is queued. For queued requests, the system 
determines which requests have mutually available us- s 
ers and indicates that those calls can be completed. 
Availability is preferably determined based on a variety 
of factors, including whetherthe user is typing at his com- 
puter, whether the user is physically in the room, and 
scheduled periods of availability for a user. The calls that 
can be completed can be ranked according to a priority 
determination. Priority is preferably determined based on 
a variety of factors including who desired the call, the 
relationship of the callers, user-specified factors, elapsed 
time since the call was requested, and anticipated call « 
duration. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0013] 20 

Fig. 1 (a) is a block diagram of the overall architecture 
of a data processing system in accordance with an 
embodiment of the present invention. 
Figs. 1(b)-1(d) are block diagrams of data proces- 2s 
sors in accordance with other embodiments of the 
present invention. 

Figs. 2{a)-2(f) are block diagrams of various exem- 
plary network organizations that can be used with 
the present invention. so 
Fig. 3 is a flow chart showing a method for requesting 
and completing a realtime message (RTM) between 
a requester and a target. 
Fig. 4 is a flow chart showing queuing a request. 
Fig. 5 is a flow chart showing checking the queued 35 
requests. 

Fig. 6 is a flow chart showing an exemplary main 

loop that processes events. 

Fig. 7 is a flow chart showing additional steps of the 

main loop of Fig. 6. 40 

Fig. 8 is a flow chart showing how to make a call, 

which is a specific example of conducting a realtime 

meeting). 

Figs. 9(a)-9(c) show exemplary user interface on a 
target's system. 4s 
Fig. 9(d) shows an exemplary user interface on a 
requester's system. 

Figs. 9{e)-9(g) show another exemplary user inter- 
face on a user's system. 

Fig. 9(h) shows an exemplary dialog box that ena- so 
bles the user to inform the system when he has com- 
pleted a call using a telephone. 
Fig. 9(i) shows an exemplary dialog box that enables 
the user to place an Internet telephony telephone 
call directly from the computer without using the tel- 55 
ephone. 



DETAILED DESCRIPTION 

General Discussion 

[0014] The present invention may be implemented on 
a computer system, such as the caller's data processing 
system 1 00 illustrated in Fig. 1 (a). It is contemplated that 
a person being called will have a similar system, as de- 
scribed herein. The data processing system 1 00 has at 
least one processor 1 02 and associated computer mem- 
ory or computer storage 104. Memory 104 includes at 
least one software component 1 12 for implementing the 
tasks described herein. The described embodiments of 
the present invention may be performed when instruc- 
tions contained in memory 1 04 orother appropriate mem- 
ories are executed by the processor 1 02 or other appro- 
priate processors. The system also preferably includes 
a database 106. Certain implementations of the system 
can also connect to a telecommunications system 1 1 6 
to place calls (or can use Internet telephony via network 
connection 114). 

[0015] Data processing system 100 also preferably in- 
cludes a network connection 114, such as a connection 
to a LAN, a WAN, and/or the Internet or to some other 
appropriate network. System 1 00 preferably includes an 
input devices(s) 118 such as a keyboard, touch screen, 
orthe like. System 1 00 preferably includes an output de- 
vice(s) 120 such as a printer, display screen orthe like. 
System 1 00 also includes a computer readable medium 
124. Computer readable medium 124 may be any ap- 
propriate medium that has instructions and/or data stored 
thereon. These instructions and data may be loaded from 
computer readable media 124 into computer memory 
1 04. Instructions and data can also be loaded into mem- 
ory in the form of a carrier wave, or by any other type of 
signal over network connection 1 1 4. 
[0016] System 1 00 also includes an operating system 
(not shown). A person of ordinary skill in the art will un- 
derstand that the memory 1 04 and computer readable 
media 124 may contain additional information, such as 
other application programs, operating systems, other da- 
ta, etc., which are not shown in the figure for the sake of 
clarity. It will be understood that data processing system 
100 (or any other data processing system described 
herein) can include numerous elements not shown in Fig. 
1 , such as additional data, software and/or information 
in memory, disk drives, keyboards, display devices, net- 
work connections, additional memory, additional CPUs 
or processors, input/output lines, etc. 
[0017] In the discussion herein, it will be understood 
that the invention is not limited to any particular imple- 
mentation or programming technique and that the inven- 
tion may be implemented using any appropriate tech- 
niquesforimplementing the functionality described here- 
in. The invention is not limited to any particular program- 
ming language, operating system, or network protocol. 
The system may use any appropriate type of telecom- 
munications systems, including but not limited to POTS 
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(plain old telephone system), cellular telephones, wire- 
less telephones, and Internet telephony. 
[0018] Some or all of the instructions and data struc- 
tures in storage area 1 04 may be read into memory from 
computer- readable media 124. Execution of sequences 
of instructions contained in the storage areas causes 
processor 102 to perform the process steps described 
herein. In alternative embodiments, hard-wired circuitry 
may be used in place of or in combination with software 
instructions to implement the invention. Thus, preferred 
embodiments of the invention are not limited to any spe- 
cific combination of hardware circuitry and software. 
[0019] In Fig. 1 (a), database 106 stores the request 
of one party to call (or meet with) another, along with 
various parameters and options about the desired call. 
Software 1 1 2 uses various metrics to decide if a party is 
available for a call, including explicit action (i.e., by the 
party running a program or invoking a function in a run- 
ning program) and implicit measurements such as track- 
ing keyboard and mouse activity, noise in the room, 
phone use, lights, door activity, motion sensors (and oth- 
er devices used by security systems), "electric eye" etc. 
Computer network 1 14, for example, is a network con- 
nection such as the I nternet or any LAN or WAN (or even 
modemcalls) to allowsome system (either one belonging - 
to the caller or a central server) to determine that two 
parties that desire a call are both available or potentially 
available forthe call (or until a quorum is available if there 
are more than two parties to a meeting). 
[0020] Fig. 1 (b) shows an alternate embodiment in ; 
which data processing system 1 00 is located between a 
telephone and the POTS system. Fig. 1 (c) shows an al- 
ternate embodiment in which data processing system 
1 00 taps into a line between a telephone and the POTS 
system. Fig. 1 (d) shows an alternate embodiment in z 
which data processing system 1 00 communicates with 
a PBX system via a network server. The network server 
communicates with the PBX system using the known CTI 
(Computer Telephony Integration) standard or another 
appropriate standard. a 
[0021] As discussed below, once a determination of 
mutual availability has been made, either of the users 
may take steps to initiate the call, either directly by com- 
puter control of the medium (the phone, or IP telephony 
or other media) or by informing one or both of the parties ■* 
that the call should be made and asking one to manually 
place it (and the other to manually receive it). 

Description of Certain Preferred Embodiments 

[0022] The following paragraphs describe certain em- 
bodiments of the present invention that are part of a "The 
described embodiment" embodiment of the invention. 
The described embodiment of the present invention is 
akin to a light on your desk that lights up when a person si 
you are trying to reach is in her office and ready to take 
your call. 

[0023] In one embodiment, when Alice wants to call 



Bob, she doesn't just pick up the phone and dial. Instead 
she picks up the mouse and clicks on Bob, or enters his 
phone number, E-mail, or other address. (Alternately, Al- 
ice can dial a standard telephone and herdialing is simply 

s input to a computer following the processes described 
herein instead of direct signaling of the traditional tele- 
phone network). These actions will register a desire to 
talk with either Bob's server, the central server or a local 
company intranet server, depending on the embodiment. 

o [0024] In this example, Bob is running the described 
embodiment client too. Because Bob's client is hooked 
to his screen saver and other applications, it knows when 
he is at his computer. If he is, and ready for her call, then 
Alice might be told she can call right away. Bob's current 

s number will pop up on the screen and she can dial it. 
With advanced phone systems, the computer might ac- 
tually dial the phone or complete the call - making it look 
to Alice just like a phone call: "dial" a number and a call 
is placed. 

o [0025] As they talk, Bob's and Alice's software clients 
are busy entertaining them and showing them ads. This 
situation is advantageous to advertisers because both 
are known to be present, and talking, but their eyes are 
free and drawn to the screen. 

s [0026] Preferably, Bob and Alice's computers know 
when Bob and Alice are finished. They may have an in- 
expensive hookup to the physical phone wires, or the 
computer's microphone may notice a lack of talking for 
a few minutes. Or they may manually click, to indicate 

? they are done, and either leaving, ready for other calls, 
or want calls held for a while. It only takes one of them 
to signal the termination of the call. Signaling the end of 
a call usually means that the user is available, although 
in certain embodiments, it may be up to the userto signal 

; availability. 

[0027] The system knows when Bob and Alice are at 
their desks, ready for calls. As soon as both of them are 
there at the same time it notices, and gets ready to set 
up the call Alice wanted. Thus, the embodiment avoids 
' phone tag and interruptions. 

[0028] Figs. 2(a)-2(f) are block diagrams of various ex- 
emplary network organizations that can be used with the 
present invention. Fig. 2(a) shows an embodiment in 
which a requester's system 202 connects to a target's 
system 206 via a network 204 such as the Internet, an 
intranet, a wireless network, or some other appropriate 
network. 

[0029] Fig. 2(b) shows an embodiment in which a re- 
quester's system 212 connects to a target's system 21 6 
via a telephone system 214 such as POTS, a cellular 
network, a wireless network, or some other appropriate 
telephone system. The systems may communicate data 
through, for example, touch tones or modem transmis- 

[0030] Fig. 2(c) shows an embodiment in which a re- 
quester's system 222 connects to a target's system 226 
via a network 224 and a telephone system 225. In such 
a system, messages about call availability might be sent 
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via the network while the actual connection for the call is 
made through the telephone system. 
[0031] Fig, 2(d) shows an embodiment in which a re- 
quester's system 236 connects to a target's system 232 
(or a target's proxy) via a network 234, but in which the s 
requester system connects to the target only via a tele- 
phone. For example, the requester may not have a soft- 
ware client installed on his computer. The requester can 
still indicate availability by calling the target system or a 
central server acting for the target (or the requester) and 10 
entering touch tones. Alternately, a target system can be 
a specially adapted telephone. 
[0032] Fig. 2(e) shows an embodiment in which a re- 
quester's system 242 connects to a target's system 246 
via a network 244 and in which a central server coordi- is 
nates the management of calls for the user systems. In 
at least one embodiment, the queue of waiting messages 
and databases for priority and sorting are located on the 
central server. Fig. 2(e) also shows optional servers con- 
necting the requester and target to the network. These 20 
servers can be, for example, proxy servers, firewalls, 
backups, or directory servers for the target or requester. 
[0033] Fig. 2(f) shows an embodiment in which a re- 
quester's system 262 connects to a target's system 266 
via a network 264. At least one of the user systems 262, 25 
264 have a primary server 267 and a backup server 268 
for added redundancy and fault tolerance, 
[0034] Fig. 3 is a flow chart showing a method for re- 
questing and completing a realtime message (RTM) be- 
tween a requester and a target. (An RTM is also referred 30 
to herein as a "call" because many embodiments of the 
invention, the purpose of the embodiment is to mediate 
telephone calls.) Examples of realtime messages include 
telephone calls, face to face meetings, and conference 
calls between two or more people. In element 304 of Fig. 35 
3, a requester sends a message requesting a realtime 
meeting. This request is sent to one or more targets. Al- 
ternately, targets and requesters may be associated with 
each other in an arbitrary graph based on requests be- 
tween parties. For example, user A may request a meet- *o 
ing with user B, and B may request to add user C. A1 1 
three parties would become parties to the meeting. 
[0035] In step 304, an RTM is queued in the systems 
of all parties (i.e., for the requester and target(s)). As 
users become available, their systems signal the other is 
systems of this availability. Similarly, if users become un- 
available, this is also signaled. 
[0036] In element 306, if there is mutual availability for 
the parties (or for a quorum if more than two parties), the 
users are so informed and allowed to initiate an RTM. In so 
certain embodiments, the system initiates an RTM with- 
out user intervention when mutual availability is deter- 
mined. In element 31 0, upon successful completion of 
an RTM, the RTMs are dequeued for the requester and 
the targets. 55 
[0037] Fig. 4 is a flow chart showing queuing an RTM 
request. The queues generally reside on the user's sys- 
tems. In a system with optional servers, if a user system 



8 

receives an RTM request from user A to user B, the sys- 
tem looks up servers that handle requests to call user B, 
In element 406, if the system of user B does not accept 
the call, the_system informs user A that the RTM request 
is denied. Otherwise, in element 408, the RTM request 
is recorded on user A's server and the system asks B's 
servers to record an RTM request from user A. 
[0038] Fig. 5 is a flow chart showing checking the 
queued RTM requests. A user might not accept a request 
by user choice or preprogramming. In element 502, the 
system finds the queued RTMs that are for users who 
are mutually available. Mutual availability means, at a 
minimum, that both users are present and available to 
talk to or meet with each other. Various embodiments of 
the present invention use various criteria for determining 
availability. For example, availability events can include 

Start or end of call or other use of phone. 

Off-hook: Unavailable 

Recently off-hook: Probably available 

Recent activity at computer input devices (mouse, 

keyboard etc.) 

Probably available 

Conversation near microphone 

Available but possibly in meeting. Possibly Available 

after conversation stops. 

Lights turned on/off (based on time of day) 

Possibly available if lights turned on recently and still 

on. Not available after lights off outside daylight 

Weight in chair or on floor 
Possibly available if sitting in chair 
Motion sensor triggers/stops triggering 
Available if recent motion sensed in room 
(others as needed) 
Opening/closing of door 

User may configure "door closed" as a signal of un- 
availability. 
Spoken commands 

Simple voice recognition (closest match) on phrases 
such as "hold calls" etc. 
Computer keyboard/mouse based commands 
User may of course set availability state, or even 
browse pending calls using computer interface 
Touchtone commands 

If system is able to listen to DTMF tones from phone, 
users may prefer to use these to substitute for com- 
puter commands. 

Remote access touchtone commands 
If user is not at desk but using remote phone inter- 
face, touchtone codes (andcaller ID information from 
incoming call) to control system, change location, 
set availability status. 
Scheduled periods of availability 
User may have default periods when they are always 
available unless they signal otherwise or metrics sig- 
nal otherwise. The system may determine his avail- 
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ability by reading the user's calendar. 

[0039] in certain embodiments, availability can take 
several states, which interact with request priority. In ad- 
dition, availability to a given party generally requires that s 
there is not another party or parties for whom simultane- 
ous availability is also present when the RTM with that 
party or parties is of higher priority. 
[0040] Certain embodiments allow requesters and tar- 
gets to specify their availability during a predetermined w 
time period, such as the estimated duration of the RTM. 
[0041 ] Once availability has been determined, mutual 
availability is determined. Mutual Availability communi- 
cation and determination depends on combination of all 
user's privacy rights and demands forthe particular com- w 
munication. Options include but are not limited to: 

1 ) Party always sends any change in availability sta- 
tus over network to other parties for whom an RTM 
request is queued. Both systems immediately detect 20 
mutual availability, and move to call-setup negotia- 



2) Party does not send availability changes, but que- 
ries remote availability for parties in RTM request zs 
queue from time to time or on change of status 

3) Party transmits availability changes and status to 
trusted 3rd server. So do other parties. 3rd server 
detects mutual availability and informs one or both 30 
parties. 

[0042] In all cases a proxy server may act for a direct 
user, and polling may take the place of "push" transmis- 
sion of status/availability information. Availability status as 
is user-specific. A user may be available to one person 
but not to another. Transmission of state information may 
be one-way, i.e. one party may be willing to tell the other 
of state, but not expect reciprocal information. Normally 
the party desiring the call will reveal state, and the recip- w 
ient will hide it unless specified otherwise. Queries, if 
made, may be anonymous or identified. Users may reject 
anonymous queries, and keep records of identified que- 

[0043] Any program hooked into the screen saver in- 45 
terrace knows when a user is using his computer. If the 
user is using his computer, he is presumed to be in his 
office. And unless he does a simple click to asks to hold 
his calls, he is ready for calls. Other simple hardware can 
look into other clues, such as sound, or the lights being so 
on. Forthe serious user, small pressure sensors in chairs 
or a pair of photocell door sensors could do the trick. Or 
the user's receptionist can track when he is ready for 
calls, as human assistants normally do. 
[0044] If the user forgets to hold calls, his first call does ss 
not need to actually ring. It rings on the computer and 
pops up a window to ask if the user wants to engage it 
(see Fig. 9). The user can either do that, or hold calls as 



if he isn't in the office. 

[0045] In element 504 of Fig. 5, the system sorts the 
messages having mutual availability in accordance with 
a message priority. These priority sorting factors can in- 
clude, but are not limited to: 

Who desired call 

Calls the user initiated are normally more important 
than ones others initiated to the user. 
Relationship {customer/suppiier/family/friend/col- 
league etc.) 

Calls with customer more important than suppliers. 
Calls with family/friends may be higher or lower in 
priority than others. Boss gets more priority than sub- 
ordinates etc. All user tunable. For customers, level 
of service customer has purchased or other factors 
related to importance of customer may also factor in. 
Manually input priority factors (both users, both per 
call and per user) 

User may specify default priorities for different peo- 
ple. 

User may also examine screen of pending queued 

calls and alter their priority. 

Elapsed time since RTM requested 

The longer somebody has been waiting for a call 

since asking for it, the more important. 

Expiration time on RTM request 

If the caller indicated the call needs to take place 

before a certain time, the closer it gets to this time 

the more important it is. 

Expected remaining time of availability 

If one party indicated they will only be available for 

a limited time, such calls are more important. 

Anticipated call duration 

If the call is expected to be short, it may get a higher 
priority. 

Past history (call difficulty, truthfulness, call frequen- 
cy) 

Parties not called frequently may get more or less 
priority. 

Parties that have lied in providing call information 
may get much less priority. Parties with a history of 
the period between call queuing and initiation being 
long may get a higher priority, ("hard to reach peo- 
ple") 

[0046] The system can be programmed to treat differ- 
ent people differently. Some can getthrough when others 
cannot. A user's family might get through any time their 
request has a priority of urgent. The user's co-workers 
and key customers might have higher level access. Cold 
callers would have to identify themselves, and say what 
the call is about. That text would appear on the screen 
before accepting a call. 

[0047] Cold calling stockbrokers might willingly identify 
themselves that way because anybody who lies more 
than a few times about their purpose in calling could be- 
come blacklisted in the ranking database (see for exam- 
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pie Fig, 9(c)). If they try to call anybody at all, the fact that 
they are blacklisted will be featured prominently for the 
user to see before deciding to accept. Thus, while the 
user can use the described embodiment in a very simple 
fashion, to be in or out, if he wants to, he can also finely 
tune it to be in or out for different classes of people at 
different times. 

[0048] In element 506 the system negotiates a cali with 
a highestpriority party. In element 508, the system places 
the call (or indicates a willingness to receive and waits 
for the target/system to place a cali). 
[0049] Figs. 6 and 7 are flow charts showing an exem- 
plary main loop that processes events . The Server Main 
Loop preferably includes the following: 

Receive requests and status information from out- 
side servers 

For those servers that can't push, or which haven't 
made contact in long period, poll at suitable polling 
interval ; 
Do polling based checks on user availability. (Also 
receive and respond to event based information 
about availability) 

Detect when both parties are available for call. 

Send status change information to secondary serv- i 

ers, and partner servers enabled for this information. 

[0050] The events processed by the server include but 
are not limited to: 

User is available for a call-out 
User is unavailable 
User ready to be called 
Target now unavailable 

Target is available 3 
- Target soon available 
Incoming RTM request 
Change an RTM request 
Overt availability request 

Call denied 4 
Synch request (from other server for user) 
New data from server 

[0051] Fig. 8 is a flow chart showing how to conduct 
an RTM (for example, how to make a telephone call). In * 
element 804, the system determines who should initiate 
the call and determines the medium to be used for the 
call. The described embodiment can also easily resolve 
problems of who calls whom. Traditional phone tag puts 
the cost of a call on whoever was "it" when the calls » 
clicked, and business usually accepts this. But if desired 
and mutually agreeable, the system can be configured 
so that the person who first requested the RTM is asked 
to make the call. Or perhaps the supplier always pays 
for the call, even if the customer initiated it, like an 800 ss 
number. Perhaps the person with the most annoying call 
screening initiates the call, or the person for whom it is 



[0052] In some cases a user might not want people to 
even know his phone number. In this case he would ask 
to always make the call. In one embodiment, the parties 
request a central server associated with a telephone 

s company to create the call by having the telephone com- 
pany call both of the users and hooking them together, 
somewhat like a conference call. Thus, neither needs to 
reveal their telephone number. Alternately, the user 
might be at a phone booth, or hotel, or foreign telephone 

10 and have a hard time making, or receiving calls. He might 
not even be at his normal number. He might be on the 
road, and tell the system his temporary number using its 
telephone or web interface. Then calls could be sent to 
him at his current location, even if the caller entered his 

15 "base" phone number when dialing. 

[0053] In element 806, the user's system initiates or 
waits for a call. While waiting, it continues to receive 
events. If it initiates and the call fails in element 812, the 
user system sends a notice of the call's failure to the 

?o otherparty'sserversandtothecentralserver. Otherwise, 
the system waits for events (see Figs. 6 and 7). Certain 
embodiments may also display advertising or update sta- 
tus windows during a call. 

[0054] In element 808, when the call ends, the system 
's signals the end of the call to other servers and dequeues 
the call from the pending call list. Certain embodiments 
also log the call. In certain embodiments, the system also 
must explicitly state that its user is available. 
[0055] Figs. 9{a)-9(c) show exemplary user interface 
io on a target user's system. Fig. 9(a) shows an exemplary 
dialog box stating that a particular user ("Bob") has re- 
quested an RTM (call) with the target user. The target 
may decide to accept or reject the call. Fig, 9(b) shows 
an exemplary dialog box resulting from a request from a 
s high priority user. In such as case, the message may 
appear on the target's screen even when the target is 
busy or not available to regular users. Fig. 9(c) shows an 
exemplary dialog box resulting from a request from a 
user who has previously been rated as untrustworthy (ei- 

0 ther by this target or by the community in general). His 
rating is displayed along with a notice that he desires a 
call. 

[0056] Fig. 9(d) shows an exemplary user interface on 
a requester's system. In this example, the requester had 
5 previously tried to contact Bob, but was unsuccessful. 
Now Bob has become available. The requester can ac- 
cept or reject the call with Bob. 

[0057] Figs. 9(e)-9(g) show another exemplary user 
interface on a user's system, where the user is both a 

1 requester and a target for different ones of a plurality of 
RTMs. The display of Fig. 9(e) is preferably displayed on 
a user's system most of the time. The display shows the 
status of requests for RTMs that have been sent to or by 
the user. For example, if the user has been out of the 

; office orotherwise unavailable, RTMs have been queued 
in his absence. The display includes, for each request, 
a status of the requester (e.g., in, out, or unknown); an 
age of the request; the name or identity of the requester, 
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a priority of the request, a reason for the request (if pro- 
vided by the requester) and information that the system 
knows aboutthe requester (e.g., telemarketer (93% prob- 
ability). In the box of Fig. 9(e), an incoming call could 
cause the specified caller to blink and be moved to the 
top of the display, along with ringing-style sounds. Alter- 
nately, the specified caller could pop up in a dialog box 
allowing confirmation that the call should be accepted. 
[0058] Fig. 9(f) shows a dialog box that preferably is 
displayed when the user returns to his system and po- 
tentially becomes available (as determined by the system 
or as indicated by the user). This box (which could also 
include advertising) shows the number of requests for 
RTMs by the user that are pending, the number of re- 
quests for RTMs from other users to the user that are 
pending, and the number of users (both targets and re- 
questers) that are available, unavailable, and unknown. 
In the described embodiment, the user may indicate that 
he wants to 1 ) become available immediately, taking the 
top priority pending request for RTM, 2) remain unavail- 
able, or 3) remain unavailable, but decide to conduct 
some of the pending calls/RTMs. If the user conducts 
RTMs (makes calls or arranges meetings) he can dial 
these himself or he can let the system dial. As mentioned 
above, the user may initiate an RTM when he is the re- 
quester orwhen he is the target, as long as there is mutual 
availability between the target and requester. Preferably, 
if the user does not respond to the box in a predefined 
period of time, a default action configured by the user, 
such as remaining unavailable, is taken and the box re- 
moved. 

[0059] Fig. 9(g) shows a dialog box preferably dis- 
played when the user conducts an RTM (places a call or 
arranges a meeting). The dialog box shows one or more 
of the following, although it will be understood that other 
information or less information could also be displayed: 
that the user called (or that the other party called if ap- 
propriate); the call duration, the local time and remote 
time (e.g., PST and EST); the date of the last call with 
this user; the total number of calls with this user; the rea- 
son for the call (if provided) and other information about 
the other user from local databases. The dialog box also 
preferably includes call billing information, a link to the 
caller's web page, and the status information shown in 
Fig. 9(f) about pending calls. 

[0060] In addition, the dialog box of Fig. 9(g) preferably 
includes buttons that let the user decide whether to end 
the call and take the next call (checked only at the end 
of the call); change the class of the call; end the call and 
hold calls; rate the caller (e.g., untrustworthy or high pri- 
ority); change the type identifier of the call; configure spe- 
cial parameters for the user or the call; customization of 
the look and feel of the interface or other aspects of the 
software 1 1 2; and phone controls (if connected to a PBX 
via the CTI standard). The dialog box also preferably dis- 
plays a picture of the caller. 

[0061] Fig. 9(h) shows an exemplary dialog box that 
enables the user to inform the system when he has com- 



pleted a call using a telephone. The user is preferably 
also prompted with information to help place the call. 
[0062] Fig. 9(i) shows an exemplary dialog box that 
might occur when placing an Internet telephony tele- 
phone call directly from the computer without using the 
telephone. 

[0063] The following paragraphs provide additional in- 
formation about the above-described embodiments and 
additional embodiments of the present in 



Call-Waiting 

[0064] Not only can trusted people get through when 
the user is holding calls, they can even get through when 

« he is on the phone (see for example Fig. 9). This embod- 
iment tells the user who the caller is, and allows in most 
cases a quick text message or reply, similar to instant 
messaging, implementation of which is known to persons 
skilled in the art. In at least one embodiment, no beep 

20 sounds and thus, a person on the other end of the phone 
during a currently occurring telephone call does not know 
that another call is available to the user. 

Not just phone calls 

25 

[0065] The described embodiment can also schedule 
face to face meetings in larger organizations, when two 
or more people are ready to meet, and want to do it as 
soon as all of them are in the office and free for a meeting. 
so The embodiment notices this and gives them all a mes- 
sage to attend the meeting. 

IP Telephony 

35 [0066] If the user wants to use IP telephony (particu- 
larly over corporate intranets where it can work reliably, 
but also over WANs), the described embodiment knows 
whether both parties have such equipment, what quality 
of equipment they have, and whether they desire to use 

4 ° the equipment, and can arrange such a call. In some 
embodiments, it can actually make the call. 



Netmeeting and Videophor 



[0067] The described embodiment's database knows 
whether both parties have things like Microsoft Netmeet- 
ing or other data collaboration tools, and in particular if 
they both can send and/or receive video phone calls. If 
so, it can call Netmeeting for a shared whiteboard and 
other shared applications, and initiate a video call either 
on its own or to go with an ordinary phone call. Currently, 
nobody uses video phone calls because it is too much 
work to know if the other person has the equipment and 
set up the two ends simultaneously. The described em- 
bodiment can let the computer worry about all this. 
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Out of the office 



[0068] In certain embodiments, paying 
could get a remote, touch-tone interface, so that they can 
declare themselves available to be called at a remote 
number. Instructions can be left as audio files. With voice 
recognition or touch-tones, more complex directions 
could be given. Depending on how much they are trusted, 
users could also be led through the "try and find you* 
chain. The described embodiment could also control 
such systems, attempting to find the user and remem- 
bering when the user is located. 



[0069] Certain embodiments provide mechanisms to 
control the flow of personal information (such as when a 
user is in a specific place, such as at the phone.) Some 
parties will receive live updates of this information, some 
will not. Other embodiments allow the user to configure 
how much information can be sent to particular other us- 
ers and when. For example, unknown other users would 
be classed as strangers, but some users might be 
classed as co-workers, family members or "intimates" of 
various levels. Such intimates would receive messages 
about the changes in status of the user regardless of 
whether they initiated the call request or the user did. 
Some intimates might even be able to query status before 
making a call request. 

[0070] Normally strangers requesting calls would not 
be given information on the target's real time availability. 
Instead, they would send the target their own availability 
information, and let the target's system decide if the par- 
ties are now mutually available. Some embodiments will 
provide an interface for users to easily change the prop- 
erties of callers and targets, particularly when acall/RTM 
is pending. Certain embodiments require a requester to 
provide a password before the target system will accept 
a request for an RTM. 

Mistakes 



[0071] Software 112 will make occasional mistakes 
about a user's availability. In a system that automatically 
determines availability, for example, if the user leaves 
his desk, it will take it a few minutes before the system 
decides that the user is gone and no longer available for 
calls. A few such calls will get through, but the other user 
can always call back. 

[0072] From time to time, for people not on trusted lists, 
there will be race conditions, where A approves the call 
of B at the same time B is setting up a call with C. Rea- 
sonable system response times will cut any time wasted 
by this to a minimum. 

Embedding 

[0073] Preferably, software 112 is embedded in the 



screen-saver information-push tools, such as PointCast, 
Backweb, Wayfarer, Netcaster, Netmeeting, and Active 
Desktop. Preferably, software 1 12 is also integrated with 
computer telephony systems, so everything is controlled 
s by one system. 

Call Centers 

[0074] Call centers for customer support can use the 
io present invention. Instead of keeping users on costly 800 
number hold, the users could request RTMs intermedi- 
ated by the user with the call center personnel. As soon 
as a customer rep was available at the call center and 
the user needing help was also available, the call would 
15 be placed. 

[0075] Call centers, thus, market or distribute the basic 
client software 1 1 2 to their own customers. Imagine the 
hold music at major companies saying, "Tired of waiting 
on hold? We don't want to make you wait. Download our 
20 client today and we'll call you when it's convenient for 
you." 

Please Hold 



: [0076] Indeed, the present invention might eliminate 
the words "Please Hold" from the vocabulary at least for 
long-term holds. Instead, the requester would make his 
request for an RTM, disconnect and re-connect when 
both parties are ready. This use is especially effective 
with new phone methods like ISDN and IP telephony that 
have very low (under 1 second) call dialing and connec- 
tion times. Integration with call center systems, and PBX 
computers can make the process almost invisible to us- 
ers of those systems. 

Components of a real-time multimedia meeting (RTMM) 
facilitation system 

[0077] An RTMM is typically a telephone call, but may 
be a real life meeting, video-call or a digitally intermedi- 
ated meeting (chat, shared whiteboard) or any mixture 
of the above. 

a) A collection of recordings of the desire for one 
user of the system to have a one-time RTMM with 
one or more other users of the system. This collection 
may be centralized, or stored with "client" compo- 
nents of the system associated with the users, or a 
mixture of these. 

b) Metrics to determine whether a given user of the 
system is ready and available for an RTMM, or an 
RTMM with specific other parties. These can include 
both direct input of desires or other status by the user 
to a software system, data gathered by observation 
of activity on the user's computer system, telephone 
or otherelectronic tools in the possession of the user, 
or data gathered from transducers associated with 
the user, measuring such things as sound, the pres- 
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enoe of lights, the presence of weight on the floor or 
in a chair, or motion or physical presence as detected 
by motion sensors or cameras. The use of thesystem 
itself to arrange RTMMs also provides such a metric. 

c) A central server to which these metrics are com- s 
municated, particularly when they change, so that 
the server can compute when all the parties to a de- 
sired RTMM are present, available and willing, and 
initiate the RTMM. Alternately an ability for local cli- 
ents to connect directly with the systems of other 10 
users to communicate the metrics, compute whether 
the time is right for a call and initiate the RTMM. 

d) Systems to initiate an RTMM, either by informing 
users it is now appropriate to make a specific tele- 
phone call or RTMM initiation (and possibly providing w 
information on how to make the call), or actually in- 
itiating the RTMM through media such as computer- 
controlled phone dialers, computer controlled te- 
lephony, computer based telephony, or computer 
based orcontrolled digitally intermediated meetings. 20 

e) Systems to detect the end of an RTMM, either 
with metrics or input from the user, to alter the avail- 
ability status of the users. In addition, upon success- 
ful creation of an RTMM, the recorded request for 
the RTMM is marked as having been acted upon, ?s 
and is removed from or no longer active in the data- 

f) Systems to allow users to exercise control over 
their availability for an RTMM with different other us- 
ers or classes of users, and to optionally confirm de- so 
sires before meetings are initiated. 

g) Systems to record preferences of users regarding 
who should initiate and/or pay for manually set-up 
RTMMs and other policy matters, and to brokerthese 
decisions, as well as preferences fortypes and times as 
of meetings to broker these decisions as well. 



call, in which case A is not informed until B reverses 
this. B may refuse the call request, in which case A 
is informed, and perhaps gets a message stating the 
reason, or a suggestion about what to do to get ac- 
cepted. 

d) B may also discard the call, which means as far 
as A is concerned the call remains active until some 
"expire" time set by A, when unfulfilled calls vanish. 
A will probably figure it out. 

e) A is a type of caller (phone solicitor) that B does 
not take calls from. 

A is told immediately that the call is not accepted, 
but warned that misrepresentation may cause revo- 
cation of the right to make calls or requests 

f) A declares the call to be urgent 

If A is the sort of caller who can make such a decla- 
ration, B will be informed, on screen, of the call even 
if not totally available (i.e. in a call or meeting, or 
screen saver is active) 

g) A is very close to B 

If A is family or some other close relationship, A may 
be able to access information on B's status, for ex- 
ample how long it has been since B was available, 
whether B is in a call and perhaps even whom B is 
talking to. 

Who pays for the call? 

[0079] This preferably is determined by several fac- 
tors: 

Who wanted the call? 

All other things being equal, the person who wanted 
to originate the call would dial the call and pay for it. 

Additional details 



Some example of certain preferred embodiments 

[0078] Alice (A) wishes to call Bob (B), but B is not *o 
available. When they are both simultaneously available 
(and don't have a higher priority call pending), different 
things may happen, depending on their relationship. 

a) A and B are close associates 45 
A is informed, and the call is initiated, normally by A. 

B's computer does display that the call is coming, 
but may not know about it until the phone rings. 

b) Two less close associates: 

B is informed of A's desire to call. B either confirms so 
and the call is initiated. If A is to call, A will be informed 
B is available and will place the call. Otherwise B 
calls, and A may not know about it until the phone 
rings. A may also indicate she is not ready, and delay 
the call. B is informed of this briefly and the call waits ss 
for A to reverse this. 

c) A and B are strangers 

B is informed of A's desire. B may elect to delay the 



[0080] A user might also have his computer screen 
calls and let in only the calls it has queued for him, either 
with caller-id or asking user to enter a couple of touch- 
tones (they were given them when their computer ok'd 
that it was time for the call). 

Computer intercepts incoming calls 

[0081] The user's computer (presumably via voice ca- 
pable modem) intercepts incoming calls. Delivers voice 
message, waits for touch tone codes. 

a) If currently about to make call: 

Indicate this, ask to queue, provide code for urgent 
over-ride (Detect caller-ID of expected call just in 

b) If currently expecting a particular call 
Indicate this, ask to enter code number for that call, 
or user caller-ID to identify user. Otherwise request 
caller hang up and queue their own call now or later. 
Allow urgent over-ride. 
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c) If not currently expecting or making cat) 
Explain The described embodiment system. Accept 
permanent access codes or caller ID of known par- 
ties if available to them, and put such calls through. 
Otherwise tell caller how to queue a call. 

d) If caller doesn't have computer, allow queue via 
touch tone, or assist in screening call. 



araftere 



inglDofpartythet 



to call 

[0082} If the local (optional) server is known from 
name, the system attempts to contact it. It does a DNS 
lookup to find codes for secondary servers, and attempts 
to contact them. It contacts a master server for informa- 
tion on what serverto contact. Any server preferably can 
redirect attempt to another server. 



For meetings instead of ci 



[0083] Simply send instructions to all parties to meet- 
ing that it is time to meet, rather than initiating call 



[0084] Await availability of all parties or all key parties 
plus some fraction of secondary parties. Then initiate 
meeting or conference call. 

Forward-on-busy call forwarding 

[0085] Second number receives call and uses caller- 
id info and other call screening techniques to duplicate 
screening process. This function maybe at acentral serv- 
erratherthan facility run by the user. An Emergency code 
can cause computer to inform user of emergency call. 



Both parties call central 'conference* system. 

[0088] If both parties are unable to easily make non- 
800 calls or place calls at all without great expense, a 
central hub may be used. This hub may have BOO num- 
bers for the two or more parties to call (a traditional con- 
ference call center) or may be able to call the parties, if 
billing arrangements are possible. Example - overseas 
locations where calls to USA are expensive but calls from 
USA are much cheaper. A central system calls both par- 
ties (or all parties) and connects them. 



[0089] Pager number or e-mail address is made avail- 
able. A call is initiated by paging/requesting party who 
then calls other party or call center. 

Call Center Version 

[0090] Unlike single system, calls can be directed at a 
pool of several possible recipients. First available recip- 
ient handles call, removed from queue immediately so 
that others will not handle it. Ability to receive availability/ 
scheduling information for the call center staff from call 
center's own computer systems. Additional priority fac- 
tors - customer service level, time spent on hold etc. 
Callers actually on hold intermixed with queued calls. 

General Comments 



Call Initiation types 

[0086] System knows whatsortof equipment each end 
of the call has, and the current situation of each party. 
These parameters affect how the call is actually brought 
about. The parties confirm initiation or accept automatic 
initiation based on preferences and per-caller/callee pref- 
erences. While computer dialing is preferred if available, 
the user may elect to use manual dialing. If computer 
reception in place, automatic dial handles it automatical- 



ly)- 

Computer reception v 



[0087] A party may answer own phone, or have com- 
puter device answer the phone as described above. A 
human or electronic receptionist may also screen call 
and know when to forward to receiving party. IN a similar 
way, the system knows the preferences of its user and 
uses one of an ordinary analog phone, digital (voice over 



a) The basic implementation of software 112 in- 
volves messages. Each system, both servers and 
clients and sub-servers, would normally wait for 
events, and then act on them. Events would include 
making a request to queue an RTM/request, and 
changes in the availability of a calling or called party. 
Events also include changes in information that de- 
termine the availability, and of course all the events 
of a call - attempting connection, reconfirming avail- 
ability, making the connection (ie. live audio or meet- 
ing) and then closing down the connection. 

[0092] However, it may be necessary in some cases 
to "poll" for status rather than simply accepting events 
so that change status. For example, if Internet filters, prox- 
ies, or firewalls make receiving incoming messages im- 
possible, a client may have to poll every few minutes to 
check status. (This is quite common in Internet "push" 



one embodiment involves two software clients, which talk 
directly to one another once they have figured out where 
they are on the Internet. However, in practice, interme- 
diate servers can be used for the following purposes: 
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a) To map a human name or phone number to the 
current Internet address for the person to be called. 

b) To deal with changing Internet addresses (due to 
DHCP dynamic host configuration) or to deal with 
shared Internet addresses, as when network ad- 
dress translation is used. 

c) To broker status and connections between stran- 

d) To record records on users, ie. so that one user 
may brand the other a liar if they called with a false 
opening message 

e) e) To proxy connections to users behind firewalls. 

f) To allow polling by users behind such firewalls 

g) To receive advertising control information on the 
free client. 

[0093] In certain embodiments, servers would include 
the "main" servers run by a central company, and proxy 
servers run by corporates who buy that software. Gen- 
erally calls between strangers (two people who have nev- 
er called one another) would start through a central serv- 
er. Once parties know one another, it may be possible 
to call without the central server if they have static net- 
work addresses. If they have a dynamic or not perma- 
nently connected address, they may need to use a central 

[0094] A call can still be rejected even when both par- 
ties are generally available. This is to protect the users' 
privacy. If a stranger calls a user, the stranger doesn't 
normally find out whether the user is available or not. 
Rather, the user can see whether the stranger is in or 
not (the strangers send the user a status change mes- 
sage) and then when the stranger is available and the 
user is ready for a call, the call gets made. On the other 
hand, a user may have an accidental signal of availability 
or unavailability, and want to reverse it. In this case, the 
user's system sends out availability and the called party 
sends back its time for a call. At that time the user may 
decide to abort. If the user decides to abort often, it gets 
noticed by other users and affects their rating, much like 
a person constantly ringing your phone when you are not 
in who leaves caller-id records. 

[0095] As noted, the technology while focused on the 
telephone call really arranges any sort of real-time "meet- 
ing." That includes face to face meetings. I.e., A user can 
request a meeting with his boss. When both are available, 
both systems notify the parties. 
[0096] In certain embodiments, when a software client 
is initialized, it checks in with its server. There it can find 
out if there is a new client update available for the user, 
and download any new ad information. The client's basic 
state as being "up" is recorded by the server so the server 
can know to send it events as time goes by. Normally the 
connection would not be permanentthough firewalls may 
force it in some instances. If the client uses a sub-server, 
that server is normally in charge of informing the master 
server about things. One reason to check with a sub- 
server is that this server will have been receiving state 
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change information on parties for whom the user has 
queued calls while the user's client was down. The star- 
tup can sync this information if it's available, and update 
the user's system information. 

s [0097] RTM requests may come in directly, or may 
come through the server the client is connected to. RTM 
requests from strangers normally come in this way, to 
avoid disclosing private information to the stranger. In 
addition, servers may be used to anonymize communi- 

10 cation, ie. both parties talk to the server so neither one 
(or anybody snooping) gets to see who is talking to whom. 
[0098] Clients normally tell the central server they are 
going down (unavailable f orf uture messages until further 
notice.) However, they will ping every so often, and a 

is server that doesn't get pings will record the client down. 
Servers also have backup servers. If they go down, cli- 
ents know to use the backup servers. When a server 
comes back up, it signals the servers that were handling 
its load, and they synchronize data and pass the load 

20 back to the server. 

[0099] The actual sequence of a call is broken down 
into the following subtypes: 

a) A calls non-intimate B, but B is not available. A 
25 now regularly informs B of any changes in status. If 

B's system notices A is available, and B is available, 
B's system tells A it is time for the call. The systems 
decide who will actually call, and call is triggered. 

b) A calls intimate B. Now A and B both inform the 
30 other of any change in status. The newly available 

callerwill, in sendingthe new status, indicate it wants 
to start a call, and systems will go into deciding who 
will call and the call is triggered. 

35 [0100] If call is overcomputernet.it is negotiated there. 
If the call is over POTS, computer net and POTS net work 
together. A dialer (not always the same as requester of 
the call) makes call. This either happens because the 
Dialer's computer is able to make the call (i.e. a modem 

io or CTI) or the dialer's computer pops up a message say- 
ing, "Now dial xxx-xxxx, and ask for Mr. Jones". The Di- 
aled party's system goes into a waiting state, if it controls 
a modem answering the phone, it waits for the call. The 
call, when it comes in, will issue touch tones to get 

is through. Other callers who sneak in during this period 
can get diverted in some fashion (a short message and 
disconnect). If a user is answering his phone and system 
can't detect this, one of the users has to click that the call 
is active (or if they don't click anything after a while, it's 

50 assumed to be.) During all this, both callers are unavail- 
able to others except those who can interrupt. 
[0101] During the call events can still come in and be 
processed. The only one that is special is the request for 
interrupt, which can come from intimates who are ena- 

55 bled to do this, or those who declare an emergency. 
(Such declaration usually must go through central serv- 
ers so it can be tracked to determine the trustworthiness 
of the user.) An interrupt doesn't stop the call but does 
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pop up a message saying a caller wishes to interrupt. 
This may include text from the caller. The user can then 
accept the interrupt (much like call waiting) or deny it, 
possibly replying with some text. 
[01 02] A call failure (no answer) indicates the recipient 
is probably not really available, even though they are 
signaling this. This will cause their computer to flash (and 
even speak) a message asking the user to update their 
status. If the user doesn't respond, they will get marked 
unavailable. Especially if there are other clues to assist, 
like along idle time. This leaves a window on the screen 
to indicate the change when they come back. 
[0103] When a user is unavailable (for example their 
screen saver has turned on) then when they return and 
touch the computerthey will be on the path to being avail- 
able. However, they will not generally be marked avail- 
able to all immediately. A small window may pop up say- 
ing, "Do you wish to be available now" which will let them 
say yes, no, or click on callers to which they will be avail- 
able. 

[0104] However, if they have calls pending from inti- 
mates, those intimates may get a message of "pending 
availability", which they can use to decide if they want to 
urgently request a call, even before the user had had a 
chance to look over their call queue. 

When one user is not at a computer 

[0105] In at least one embodiment, RTMs (mainly tel- 
ephone calls) can be made where one of the parties is 
not at a network-connectable computer, or is not even a 
user of the system. Users registered in the system who 
normally use it from their "base" computer may be away 
from the system but still wish to use it to intermediate 
telephone calls. (Away from the system it is less likely to 
use it to arrange meetings.) 

[0106] This can take place in a variety of ways, among 

a) The party can, while using a computer, enter a 
schedule of both availability, and the telephone 
number at which the user will be reachable. For ex- 
ample, they might specify that for some or all callers, 
they will be available by at a cellular phone number 
either at specific times, or all times that they are away 
from a network connected computer. They might al- 
so schedule times to be available at a home number 
or remote numbers or even hotels. 

b) The party might reach a general computer which 
has a web browser, and, using an access code, use 
general web pages associated with either central or 
proxy servers or their client to change and update 
theirstatus andschedule and phone number. An "ap- 
plet", using the Java system, might well provide them 
with much of the interface they are used to, even at 
a remote computer. 

c) The party might call into to their own computer (if 

it answers the phone) or a central server. Once called 
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in they could, through the use of touch-tones or voice 
recognition, give commands to alter their status and 
location for some or all other parties. If possible, they 
might do this simply, communicating the phone 
s number they are at through the use of Caller-ID or 
Automatic Number Identification (AN I) to an 800 
number. In this case, availability would be triggered 
shortly after hanging up this control call. 

10 [0107] If calls are made with other parties who are at 
network connected computers, the other parties will pro- 
vide signals to the system, to be sent to whatever system 
is controlling the user's calls, about when the user starts 
and ends calls with whom. If the user has a call with 

« another party who is also not at a network connected 
computer, 

the system will either have to be told with another call 
that this call has ended, or simply have to guess. In such 
circumstances, the use of a central server which calls 

20 both parties and connects them has advantages. 

[01 08] When a user calls in to update status with touch 
tones, they may also be able to hear, with computer gen- 
erated speech, their pending calls and priorities, and con- 
trol what orderthey are performed in. Eventually it is hope 

25 that cellular telephones in particular will provide native 
support for call intermediation using the present inven- 
tion. 

Non-users (non-members): 

[01 09] It is also necessary for telephone calls to take 
place between users ("members") of the system and non- 
users. While non-users are encouraged to join the sys- 
tem and run the necessary software, this is not a require- 
as ment. Non-users can participate in several ways, among 

a) The non-user can become a temporary user by 
visiting a web page, and requesting calls with "mem- 

40 ber" users. The web page will feature buttons for the 
non-member to indicate their availability status. This 
web page, if left on the screen, can be used for this 
purpose, updating every few minutes using automat- 
ic mechanisms. 

45 b) The non-user can download and run an "applet" 
in a web page using a system like Java. This applet 
can perform almost all the functions of the regular 
client, though it will not have access to machine in- 
formation such as keyboard idle times to determine 

so the non-member's availability. 

[0110] Users satisfied with this level of control could 
actually become members through such an applet or full 
Java application. 

c) Non-members, who would call members in the 
ordinary fashion, may have their call intercepted im- 
mediately by the member's client. This client could 
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either pass calls through if the user is available and 
has no call pending, or it could intercept the call and 
perform a semi-traditional 'voice mail* service to al- 
low the callerto leave a message. This greeting mes- 
sage would probably instruct the caller how to use s 
the system as a non-member or member, by direct- 
ing the callerto a web page with such information. 

[0111] The system could also accept touch tone or 
voice commands from the user to allow the user to enter 10 
a phone number or name. Caller-ID or ANI could also be 
used to extract this information. A call could then be 
queued in the system requesting the member to call the 
non-member when the member becomes available. It is 
also possible that the non-member could, using such in- « 
puts, specify times of availability, though the interface for 
that would be complex for an untrained non-member, (ie. 
"Enter the number of minutes you will be available at this 
number, followed by the pound sign.") Of course, as not- 
ed, the caller could just leave a message, which the mem- so 
ber could access either with a voice-mail style interface 
or ideally over the computer using their client. 

d)The operators of the central server could also offer 
telephone numbers (800 number or otherwise) for 25 
non-members to use in calling the member. These 
numbers couldfeature routing of calls to the member 
if the member is available, or special voice mail func- 
tions such as above. In these cases, when the non- 
member is not at a computer, obviously information so 
about when the non-member is available or not is 
limited. The system may be forced to work with 
guesses. However, if wrong guesses are made, and 
calls fail due to busy signals or no-answers, a mem- 
ber can record the failure to improve the guess on 
the non-member's availability. 

[0112] In summary, the described embodiments of ap- 
plicant's invention allow users to efficiently arrange 
RTMs, including but not limited to, telephone calls and 
meetings with a minimum of wasted time and effort. The 
embodiments described herein are presented as exam- 
ples only, with the scope of the invention being repre- 
sented by the following claims. 



determining an availability status of the target, 
said availability status indicating whetherthe tar- 
get is currently available for the real-time corn- 
queuing (304) the request if the target is not 
available; 

wherein, for each queued request, the following 
steps are performed: 

determining an availability status of the target of 
said queued request, said availability status in- 
dicating whether the target is currently available 
for the real-time communication; and 
determining an availability status of the request- 
erof saidqueued request, said availability status 
indicating whether the requester is currently 
available for the real-time communication; and 
taking (308) steps to cause the real-time com- 
munication to occur as soon as the requester 
and the target of said queued request a mutually 
available; 

said method characterized in that: 

the availability status of the requester is deter- 
mined by means of monitoring computer usage 
for checking whether the requester is physically 
present in the vicinity of the requester system; 

the availability status of the target is determined 
by means of monitoring computer usage for 
checking whether the target is physically 
present in the vicinity of the target system. 

The method of claim 1 , wherein the target system is 
polled to determine the target's availability. 



wherein the requc 
e the requester's a 



3. The method of claim 1 
system is polled to deti 
ability. 



4. The method of one of the preceding claims, wherein 
a plurality of requests is sent to a plurality of targets 
and mutual availability is determined when the re- 
quester and at least one target is available. 

5. The method of one of the preceding claims, compris- 



A computer-implemented method for the intermedi- 
ation of real-time communications between a re- 
quester and a target communicating to each other 
by means of a requestersystem and a target system, 
respectively, said method comprising the steps of: 

receiving (302) a request from a requester, said 
request indicating that the requester wants to 
conduct a real-time communication with a tar- 



reviewing the held requests to determine wheth- 
er the requester and the target are mutually 
available. 

The method of one of the preceding claims, wherein 
a request having the highest priority is determined 
(504) by sorting on one or more of the following fac- 
tors: who desired the call; relationship with the target 
or requester; user-specified priority, factors; elapsed 
time since the real time communication was request- 
ed; expiration time on the real time communication 
request; expected remaining time of availability; an- 
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ticipated call duration; past history; difficulty of reach- 
ing requester. 

7. The method of one of the preceding claims, including 
if the target is physically present, displaying at least 
one request identifying a requester that had previ- 
ously requested a real time communication with the 
target, 

8. The method of one of the preceding claims, wherein 
the real time communication is conducted using a 
telephone. 

9. The method of one of claims 1 to 7, wherein the real 
time communication is conducted using Internet te- 
lephony. 

10. The method of one of claims 1 to 7, wherein the real 
time communication is specified as being a face to 
face meeting. 

1 1 . The method of one of the preceding claims, wherein 
a determination of whether the target or requester is 
physically present is made by checking one or more 
of the metrics of computer usage: recent activity at 
computer input devices; computer keyboard/mouse 
based commands; and touchtone commands. 

12. The method of one of the preceding claims, further 
comprising: 

allowing the target to rate callers and to filter 
callers based on his own previously assigned 
ratings. 



Patentansprtiche 

1 . Computerimplementiertes Verfahren fur die Vermitt- 
lung von Echtzeitkommunikationen zwischen einem 
Anforderer und einem Ziel, die miteinander durch ein 
anfordemdes System bzw. ein Zielsystem kommu- 
nizieren, wobei das Verfahren die Schritte umfaSt: 

Empfangen (302) einer Anforderung von einem 
Anforderer, wobei die Anforderung anzeigt, daS 
der Anforderer eine Echtzeitkommunikation mit 
einem Ziel fuhren mochte; 
Bestimmen eines Verfugbarkeitsstatus des 
Ziels, wobei der Verfugbarkeitsstatus anzeigt, 
ob das Ziel momentan fur die Echtzeitkommu- 
nikation verfugbar ist; und 
in eine Warteschlange setzen (304) der Anfor- 
derung, falls das Ziel nicht verfugbar ist; wobei 
fur jede in einer Warteschlange stehende Anfor- 
derung die folgenden Schritte durehgefuhrtwer- 

Bestimmen eines Verfugbarkeitsstatus des 
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Ziels der in der Warteschlange stehenden An- 
forderung, wobei der Verfugbarkeitsstatus an- 
gibt, ob das Ziel momentan fur die Echtzeitkom- 
munikation verfugbar ist; und 
Bestimmen eines Verfugbarkeitsstatus des An- 
forderers der in der Warteschlange stehenden 
Anforderung, wobei der Verfugbarkeitsstatus 
angibt, ob der Anforderer momentan fur die 
Echtzeitkommunikation verfugbar ist; und 
Ergreifen (308) von Schritten, urn das Eintreten 
der Echtzeitkommunikation zu bewirken, sobald 
der Anforderer und das Ziel der in der Warte- 
schlange stehenden Anforderung gegenseitig 
verfugbar sind; 

wobei das Verfahren dadurch gekennzeich- 
net 1st, daB: 

der Verfugbarkeitsstatus des Anforderers durch 
eine Uberwachung einer Computernutzung zur 
UberprQf ung, ob der Anforderer physisch in der 
Nahe des anfordemden Systems anwesend ist, 
bestimmt wird; und 

der Verfugbarkeitsstatus des Ziels durch eine 
Uberwachung einer Computernutzung zur 
Uberprufung, ob das Ziel physisch in der Nahe 
des Zielsystems anwesend ist, bestimmt wird. 

2. Verfahren nach Anspruch 1 , wobei das Zielsystem 
gepollt wird, um die Verfugbarkeit des Ziels zu be- 



3. Verfahren nach Anspruch 1 oder 2, wobei das an- 
fordernde System gepollt wird, um die Verfugbarkeit 
des Anforderers zu bestimmen. 

4. Verfahren nach einem der vorhergehenden Anspru- 
che, wobei eine Mehrzahl von Anforderungen an ei- 
ne Mehrzahl von Zielen gesandt wird und die gegen- 
seitige Verfugbarkeit festgestellt wird, wenn der An- 
forderer und zumindest ein Ziel verfugbar sind. 

5. Verfahren nach einem der vorhergehenden Anspru- 
che, umfassend: 

Uberprufen der gehaltenen Anforderungen, um 
f estzustellen, ob der Anforderer und das Ziel ge- 
genseitig verfugbar sind. 

6. Verfahren nach einem der vorhergehenden Anspru- 
che, wobei eine Anforderung mit der hochsten Prio- 
ritat festgestellt wi rd (504) durch Sortieren eines oder 
mehrererderfolgenden Faktoren: werwunschteden 
Anruf; Beziehung mit dem Ziel oder dem Anforderer; 
nutzerspezifizierte Prioritatsfaktoren; vergangene 
Zeit seit der Anforderung der Echtzeitkommunikati- 
on; Ablaufzeiffurdie Echtzeitkommunikationsanfor- 
derung; erwartete verbleibende Verfugbarkeitszeit; 
vorhergesagte Anrufdauer; Where Historie; 
Schwierigkeit den Anforderer zu erreichen. 
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7. Verfahren nach einem cler vorhergehenden Anspru- 
che, welches umfaBt: 

falls das Ziel physisch anwesend ist, Anzeigen 
zumindest einer Anforderung, die einen Anfor- 
derer identifiziert, der zuvor eine Echtzeitkom- 
munikation mit dem Ziel angefordett hat. 

8. Verfahren nach einem der vorhergehenden Anspru- 
che, wobei die Echtzeitkommunikation unter Ver- 
wendung eines Telefons gefuhrt wird. 

9. Verfahren nach einem der Anspriiche 1 -7, wobei die 
Echtzeitkomm u n ikatio n unter Verwendung von In- 
temettelefonie gefuhrt wird. 

1 0. Verfahren nach einem der Anspriiche 1 -7, wobei die 
Echtzeitkommunikation als ein personliches Treffen 
spezifiziert ist. 

1 1 . Verfahren nach einem der vorhergehenden Ansprii- 
che, wobei eine Bestimmung, ob das Ziel oder der 
Anforderer physisch anwesend ist, durchgefuhrt 
wird, indem eine oder mehrere der Metriken einer 
Computernutzung geprOft werden: 

letzte Aktivitat an Computereingabevorrichtun- 
gen; Computertastatur-/Mausbasierte Befehle; 
und Touchtone-Befehle. 

12. Verfahren nach einem der vorhergehenden Anspru- 
che, welches des weiteren umfaBt: 

dem Ziel ermoglichen, Anrufereinzustufen und 
Anruferbasierend auf seinen eigenen zuvor zu- 
geordneten Einstufungen zu filtem. 



Revendications 

1 . Precede mis en oeuvre par ordinateur pour la me- 
diation interm6diaire de communications en temps 
reel entre un requerant et une cible communiquant 
I'un avec I'autre par I'intermidiaire d'un systeme re- 
querant et d'un systeme cible, respectivement, ce 
precede comprenant les etapes suivantes : 

recevoir (302) une requete d'un requerant, la 
requete indiquant que le requerant veut effec- 
tuer des communications en temps reel avec 

determiner un etat de disponibilite de la cible, 
I'etat de disponibilite indiquant si la cible estcou- 
ramment disponible pour les communications 
en temps reel ; et 

mettre en file (304) la requete si la cible n'est 
pas disponible ; 

dans lequel, pour chaque requete mise en file, 
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les etapes suivantes sont mises en oeuvre : 

determiner un etat de disponibilite de la ci- 
ble de la requete mise en file, I'etat de dis- 
ponibilite indiquant si la cible est presente- 
ment disponible pour les communications 
en temps reel ; et 

determiner un etat de disponibilite du reque- 
rant de la requete mise en file, I'etat de dis- 
ponibilite indiquant si le requerant est pre- 
sentement disponible pour les communica- 

prendre (308) des etapes propres a amener 
les communications en temps reel a pren- 
dre place des que le requerant et la cible de 
la requete mise en file sont mutuellement 
disponibfes; 

ce procede etant caracterise en ce que : 

I'etat de disponibilite du requerant est 
determine au moyen d'un ordinateur de 
surveillance pour verifiersi le requerant 
est physiquement present au voisinage 
du systeme requerant ; et 
25 I'etat de disponibilite de la cible est de- 

termine par un ordinateur de surveillan- 
ce pour verifier si la cible est physique- 
ment presente au voisinage du syste- 

30 

2. Procede selon la revendication 1, dans lequel le sys- 
teme cible est interroge pour determiner la disponi- 
bilite de la cible. 

35 3. Proc6de selon la revendication 1 ou 2, dans lequel 
le systeme requerant est interroge pour determiner 
la disponibilite du requerant. 

4. Procede selon I'une quelconque des revendications 
to precedentes, dans lequel une pluralite de requites 
est envoyee a une pluralite de cibles et la disponibi- 
lite mutuelle est d6termin6e quand le requerant et 
au moins une cible sont disponibles. 

is 5. Procede selon Tune quelconque des revendications 
precedentes, comprenant : 

revoir les requStes maintenues pour determiner 
si le requerant et la cible sont mutuellement dis- 
so ponibles. 

6. Procede selon I'une quelconque des revendications 
pr6cedentes, dans lequel une requete de plus haute 
priority est deterrrree (504) en triant un ou plusieurs 
55 des facteurs suivants : 

qui a demande Tappet; relation avec la cible ou 
le requerant ; facteur de priorite specifie par 
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I'utiiisateur ; temps ecoule depuis que ies com- 
munications en temps reel ont ete requises ; 
temps d'expiration de la requite de communi- 
cations en temps reel ; temps restart attendu 
de disponibitrte ; duree d'appel prevue ; histoire 
; difficulty d'atteindre le requerant. 



Procede seion Tune quelconque des revendications 
precedentes, incluant, si la cible est physiquement 
presente, d'afficherau moins une requete identifiant 
un requerant qui a precedemment requis des com- 
munications en temps reel avec la cible. 

Procede selon I'une quelconque des revendications 
precedentes, dans lequel Ies communications en 
temps reel sont effectuSes en utilisant un telephone. 

Procede selon I'une quelconque des revendications 
1 a 7, dans lequel Ies communications en temps reel 
sont effectuees en utilisant un telephone par Inter- 



10. Procede selon I'une quelconque des revendications 
1 a 7, dans lequel Ies communications en temps reel 
sont specifies comme etant une reunion face a face. 

1 1 . Procede selon I'une quelconque des revendications 
precedentes, dans lequel une determination de ce 
que la cible ou le requerant est physiquement pre- 
sents est realisee en verifiant une ou plusieurs des 
metriques d'utilisation d'ordinateur, d'activites res- 
tantes des dispositifs d'entree de I'ordinateur, de 
commandes basees sur le clavier ou la souris de 
I'ordinateur; et de commandes de tonaiite de touche. 

12. Procede selon I'une quelconque des revendications 
precedentes, comprenant en outre : 

permettre a la cible de classer Ies appelants et 
de filtrer Ies appelants en fonction de leur clas- 
sification precedemment affectee. 
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Fig. 2(b) 



Target User's system 
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Queuing a RTM 

Request 



Accept request for RTM 
from user A to target 



Fig. 4 




Inform A that RTM 
request is denied 



Ask B's servers to 
record RTM request ~ 
from A 



Redisplay, Finish 
I Event j 
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Find the parties that are mutually available 








504 


Sort (for example, by priority) 








506 


Negotiate RTM with highest priority party 








508 


Place RTM (or 
indicate willingness to receive RTM and wait 
for call) 



Check Queued RTM Requests 
Fig. 5 
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Report RTM Denied and 
dequeue RTM or leave for later as 
per user command/config 



Sync data with requesting 
central server. Trigger new 
events appropriately. 



Store new data, trigger events 




appropriately 





Events Processed from Main Loop 
Fig. 7 
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Make a 
Call/ 

Conduct 
RTM 



Determine who should 
initiate the call, and the 
medium to be used for 
the call. 



Initiate or wait for call. 
Continue to receive 
events. 



During call, wait for 
events. Present 
advertising on display if 
appropriate. Update 
status windows with 
information on other 
RTMs. 



RTM ^ 
Fails ► 



Send notice of RTM failure 
to other party's servers 
and central servers 



End of call: Signal end of 
RTM to other servers. 
Dequeue RTM from 
pending RTM list. Log RTM. 




Fig. 8 
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Target User's System 
Fig. 9(a) 




Target User's System 
Fig. 9(b) 
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Call from Bob (rating of "untrustworthy"). Do you wish 
to a ccept? 



Target User's System 
Fig. 9(c) 
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Calling User's System 
Fig. 9(d) 
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PhoneMeet Status: At Desk, ? hold all calls 


Status 


Age 


Caller 


Pri 


Reason 


Info 




In 




John Chang 




Order 




Out 








Budget Chat 




link 




Harold Jenkins 




Referred bv J. Birch 




Out 


1 day 


Bob Smith 


U 


Hirine Crisis 




In 


2 davs 


Snidlev Whip 




Hot stock rip 


Telemarketerf93%) 


Blue: You called Them 


Black: They called you 







Fig. 9(e) 



Welcome back. 5 calls are pending, 2 by you, 2 available, 2 out, 1 unknown. Do you wish to: 




SI Become available, taking the top pending call [XXX call description XXX] 
O Remain unavailable 

D Remain unavailable but examine call list to make call-by-call decisions 



Fig. 9(f) 
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Running Advertisement 


Picture of Caller 


Ciller/ 

Yott called: 


John Chang 


QEnd Call (& take next call) 




Duration 


12:04 minutes 


Q Change Class (select bar) 


Local Time 


4:32pm EST 


[jEnd call & hold calls 


Remote 


1 :32pm PST 


FjRate the caller (select bar) 


Last Call 


Jan 15, 1999 


Q Change call type 


Total Calls 


12 


Q Configure special 
parameters 


Fkst Call 


May 19, 1998 


QGeneral customization 




Chat about Fred 


Phone controls (if CTI),ie. 
transfer call, etc. 


Other information from local 
databases on the caller, Ie. "John 
Chang is V P., Marketing for 
consumer division." etc. 


Box for entry of notes on 




Box for billing information 


Click to go to caller's web page 


Here would be the status window (specified in Fig. 9(f)) for pending calls 



Fig. 9(g) 
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Ready to call John Chang. 

Please pick up phone, call 555-555-5555, wait, ask 
receptionist for "bubba" (code word). 
Cli ck OK when call do ne 

OK 

Fig. 9(h) 



Calling Mary Smith by Internet IP telephone. 
Click cancel to stop. 

Cancel 



Fig. 9(i) 
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REFERENCES CITED IN THE DESCRIPTION 

This list of references cited by the applicant is for the reader's convenience only. It does not form part of the European 
patent document. Even though great care has been taken in compiling the references, errors or omissions cannot be 
excluded and the EPO disclaims all liability in this regard. 



Patent documents cited in the description 

• US 10425598 P, Bradley S. [0001] • EP 0557777 A [0006] 

• WO 9821870 A [0005] 
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RECEIVED 



2,352,165 

TEMPLETON, BRADLEY S. 

METHOD AND APPARATUS FOR INTERMEDIATION OF 
MEETINGS AND CALLS 

H04M 3/42 (2006,01) 

106-483 

Mara Gravelle 



YOU ARE HEREBY NOTIFIED OF A REQUISITION BY THE EXAMINER IN ACCORDANCE WITH 
SUBSECTION 30(2) OF THE PATENT RULES. IN ORDER TO AVOID ABANDONMENT UNDER 
PARAGRAPH 73(1 )(A) OF THE PATENT ACT, A WRITTEN REPLY MUST BE RECEIVED WITHIN 
6 MONTHS AFTER THE ABOVE DATE. 

This application has been examined taking into account applicant's correspondence received in this 
office on June 18, 2007 and October 3, 2007. 

The number of claims in this application is 73. 

The examiner has identified the following defects in the application: 

Non-Statutory Subject Matter 

Claims 57 and 73 are directed to non-statutory subject matter, and are outside the definition of 
invention in section 2 of the Patent Act, The aforementioned claims are directed towards a 
"program" A computer program product is not a programmed computer. An acceptable computer 
product claim would define a computer readable memory for storing programmable instructions for 
use in the execution in a computer of the method of the invention disclosed in the instant 
application 

Unity 

The application does not comply with subsection 36(1) of the Patent Act. The claims are directed 
to a plurality of alleged inventions as follows: 



Canada 
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Group A - Claim 1 with dependant claims 3-27 and 73 are directed to a method that 
involves a decider system for queuing and availability status; 

Group B - Claim 2 with dependant claims 3-2? and 73 are directed to a method without any 
specified systems, but a requester system for queuing; 

Group C - Claim 28 with dependant claims 30-42 and 73 are directed to a method for 
transmitting or receiving with no queueing; 

Group D - Claim 29 with dependant claims 30-42 and 73 are directed to a method to only 
receive requests with no queuing; 

Group E - Claims 43-56 are directed to system involving multiple requester systems and 
servers as well as a deciding agent; 

Group F - Claim 57 is directed to program code that is capable of receiving requests, 
queueing, receiving availability and determining mutual availability; 
Group G - Claims 58-64 are directed to a user interface to display a requester ID and 
availability; and 

Group H - Claims 65-72 are directed to a user interface to display multiple lOs and 
availabilities. 

According to subsection 36(2) of the Patent Act, after limiting the claims of the present application 
to one invention only, the applicant may make any other invention disclosed the subject of a 
divisional application. The applicant is advised that once an election has been made, further 
prosecution of the present application will be limited to the invention so elected. For the purposes 
of the present report, the examiner has proceeded on the presumption that the applicant will elect 
the claims of Group A. This presumption does not affect applicant's right to elect, one time, a 
different invention for prosecution. 

Note that, where an examiner decides, when the unity of invention problem is first identified, to 
nevertheless examine the claims of one unity group, the applicant is still entitled to elect a different 
group in response to the requisition. 

In view of the above, a search of the prior art and examination have been limited to the subject 
matter in claim 1 with dependant claims 3-27 and 73. 

A search of the prior art has thus far failed to reveal any pertinent references, 

Indefiniteness 

Claims 3-6, 12 and 19 are indefinite and do not comply with subsection 27(4) of the Patent Act. 
The use of "a system" (claim 3, line 1; claim 5, line 1), "the system" (claim 4, line 1; claim 6, line 1; 
claim 12, line 1-2) and "the three systems" (claim 19, line 1 ) cause ambiguity as it is not clear which 
system(s) are being referred to, as there is "a requester system" and "a decider system" in claim 
1 and there is no third system. These also have antecedent issues. 
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Claim 8 is indefinite and does not comply with subsection 27(4) of the Patent Act. The second 
introduction (use of an indefinite article) of an element already introduced causes ambiguity. The 
term "a request" (claim 8, line 1 ) has been defined previously in the claims. The aforementioned 
term should therefore be referred to using a definite article. There are two requests already 
introduced in claim 1 . 

Claim 9 is indefinite and does not comply with subsection 27(4) of the Patent Act, The second 
introduction (use of an indefinite article) of an element already introduced causes ambiguity. The 
term "an availability status of the target T-A" (claim 9, line 1 ) has been defined previously in the 
claims The aforementioned term should therefore be referred to using a definite article. There are 
two requests already introduced in claim 1 , 

Claims 4 and 6 are indefinite and do not comply with subsection 27(4) of the Patent Act. Claims 
containing a negative expression such as ""without being polled'*" is objectionable in that claims 
should generally set forth what the invention is or does, and not what it is not or does not do. 

Claim 1 , line 9 appears to contain a spelling error. It reads "availability statues ", it appears that this 
should read "availability status". 

Description and Drawings 

The figures and the description do not comply with section 82 of the Patent Rules. Reference 
characters not mentioned in the description must not appear in the drawings, and vice versa 
Reference characters 236 (pg. 6, line 30), 234 (pg. 6, line 31), 242 (pg. 7, line 2), 246 (pg. 7, line 
3), 244 (pg. 7, line 3) appear in the description but not in the drawings. Reference characters 180 
and 175 (Fig. 1(b) and Fig 1(c)); 190, 195, 196 (Fig. 1(d)); 252, 254, 256, 258 (Fig. 2(d)); 302, 308 
(Fig, 3); 402, 404, 412, 414 (Fig. 4); 802, 810 (Fig. 8); appear in the drawings but not in the 
description. 

The drawings must be amended to comply with section 82 of the Patent Rules. The same 
reference character must be used for the same part in different figures, and must not be used to 
designate different parts Reference character 304 on pg. 7, line 16 of the description appears to 
be a typo and should instead read 302. 

The drawings must be amended to comply with section 37(2) of the Patent Act. The drawings must 
show clearfy all parts of the invention and identify all parts by reference characters. Further, the 
description must include a written description of the drawings using the reference characters 
Figures 6, 7, and 9(a-c) do not comply. 
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In view of the foregoing defects, the applicant is requisitioned, under subsection 30(2) of the Patent 
Rules, to amend the application in order to comply with the Patent Act and the Patent Rules or to 
provide arguments as to why the application does comply. 



Mara Gravelle 
Patent Examiner 
819-934-4893 



(11) Related Proceedings Appendix 



NONE 



